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[57] ABSTRACT 

A courier electronic payment system provides customers, 
merchants, and banks with a secure mechanism for using a 
public network as a platform far credit card payment ser- 
vices. The system governs the relationship between a 
Customer, Merchant, and Acquirer Gateway to perform 
credit card purchases over such networks as the Internet The 
system uses a secure connection to sinq>lity the problem of 
Internet-based financial transactions in accordance with an 
electronic payment protocol that secures credit card pay- 
ments and certifies infrastructure that is required to enable 
all of the parties to participate in the electronic commerce, 
as well as to provide the necessary formats and interfaces 
between the different modules and systems. 

36 Claims, 3 Drawing Sheets 




11 



IB-i 21-' ^13 18-' a?J 20 



Shopping, browsing etc. 




V 



40 



Beginning of Payment Processing Protocol: 




09/16/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 23, 1997 sheet 1 of 3 5,671,279 



I 



CUSTOMER 
C 



7ZL 



7ZZZZZL. 



7ZZZZZZZZ;n2Zl 



MERCHANT 
M 



JB-^ 22-' ^19 20 



Shopping, browsing etc. 




Beginning of Payment Processing Protocol: 




FIG. 1 



09/16/2004, EAST Version: 1.4.1 



U.S. Patent Sep. 23, 1997 sheet 2 of 3 S,<S11^19 



IB- 



IB 



Purchase-Order (including PI) 

Acknowledge option 
Order-Inquiry option 
Order-Status option 

Auth-Request 
Auth-Response 



Order-Inquiry option 
Order-Status option 
\^ Receipt option 



FIG. 2 



20 



CUSTOMER 




MERCHANT 




GATEWAY 


C 




M 




G 



09/16/2004, EAST version: 1.4.1 



U.S. Patent Sep. 23, 1997 sheet 3 of 3 5,671,279 

iB-\ IB- 




20 



MERCHANT 
M 



A. 



GATEWAY 
G 



i9{ 



\ 



Receipt option 



Capture-Request 



Capture-Confirm 



FIG. 3 



iff 



CUSTOMER 
C 



IB 



MERCHANT 
M 



20 



GATEWAY 
G 



Settlement-Request 



19* 



Settlement-Con firm 



FIG. 4 



09/16/2004, EAST Version: 1.4.1 



5,6-; 

1 

ELECTRONIC COMMERCE USING A 
SECURE COURIER SYSTEM 

BACKGROUND OF THE INVENTION 

1. Technical Field 

The invention relates to the processing of commercial 
transactions. More particularly, the invention relates to the 
secure processing of on-line commercial transactions. 

2. Description of the Prior Art 

A fast-growing trend on the Internet is the ordering and 
provision of information, goods, and services via tfie World 
Wide Web, electronic mail, and other means. A key issue for 
related to such electronic commerce is the authorization and 
satisfaction of payment for such goods and services in an 
efficient, reliable, and secure manner. A number of organi- 
zations have addressed this issue by establishing proprietary 
payment systems which vary widely in design, performance, 
and security features. 

See, for example M. Linehan, G. Tsudik, Internet Keyed 
Payments Protocol {iKP), Intem^-Draft <draft-tsudik-ikp- 
OO.txt> (July 1995) (an architecture for secure payments that 
involves three or more participants in which a base protocol 
includes a number of options that can be selected to meet 
varying business or security requirements, for example by 
applying cryptographic techniques to minimize potential 
risks concerning payments over the open Internet). 

See, also L. Stein, E. Steffcrud, N. Boienstein, M. Rose, 
The Green Commerce Model, First Virtual Holdings, Inc., 
October 1994 (http://www.infohaus.com); N. Borenstein, 
M. Rose, The application/green-commerce MIME Content- 
type, First Virtual Holdmgs, Inc., October 1994 (http^/ 
www.infohaus.com); and Encryption and Internet 
Commerce, First Virtual Holdings, Inc., 1995 (http:// 
www.infohaus,com); andFlrst\toial Holdings, Inc., Wired, 
pp. 51 (Octoba 1995), MacWorld, pp. 114 (November 
1995) (an on-line transaction clearing house in which 
accounts are established off-line via telephbne, and in which 
a transaction requires an account number, where each trans- 
action is confinned by the clearing house via email); 
CyberCash, MacWwld, pp. 114 (November 1995) (an elec- 
tronic payment system that uses cryptography to prevent 
eavesdroppers from stealing and unscrupulous merchants 
from overcharging); NetCheque, University of Southern 
California, MacWorld, pp. 114 (November 1995) (an on-line 
diecking system in which an account holder can send an 
electronic document that a recipient can deposit electroni- 
cally into a bank account as a check, where the document 
contains the name of the payer, financial institution, payer's 
account number, payee's name, and amount of check, and 
which includes a digital signature of the payer and which 
may include a digital signature of a payee); and DigiCash, 
MacWorld, pp, 114 (November 1995) (an Internet payment 
systems, referred to as eCash. that provides digital money 
witiiout an audit trail, thereby protecting the privacy of 
parties to the transaction). 

Additionally, electronic conomerce systems have been 
proposed by N^a International Service Association in col- 
laboration with Microsoft Corporation (Secure Transaction 
Technology, using digital signature to authenticate a credit 
card and merchant decal; see http://www.visa.com); and 
MasterCard (Secure Electronic Payment Protocol, a collec- 
tion of elements including an authorized holder of a bank- 
card supported by an issuer and registered to perform 
electronic commerce, a merchant of goods, services, and/or 
information who accepts payment from the holder 
electronically, a MasterCard member financial institution 
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that supports merchants by providing service for processing 
credit card based transactions, a certificate management 
system that provides for tibe creation and distribution of 
electronic c^tificates for merchants, financial institutions, 

s and cardholders, and a network to interface the merchants, 
financial institutions, cardholders, and certificate manage- 
ment system; see http://www.mastercard.com). Payments in 
the real world are acconiplished via such mechanisms as 
cash, checks, credit and debit cards, money, and postal 

10 orders. Electronic equivalents of all these payment systems 
are being developed. For exanq)le, iKP, ibid, addresses a 
subset of these mechanisms that involve direct payment 
transfers among accounts maintained by banks and other 
financial organizations. This includes aedit and debit card 

IS transactions, as well as electronic check clearing, but 
exdudes electronic cash and money oxdscs because these 
require very different mechanisms. The stated goal of iKP is 
to enable Internet-based secure electronic payments while 
using the existing financial infrastructure for payment autho- 

20 rization and clearance. The intent is to avoid completely, or 
at least minimize, changes to the existing financial infra- 
structure outside of the Internet 

Payment systems incorporate tradeoffs among cost, 
timeliness, efficiency, reliability, risk management, and con- 

25 venience. For example, some systems attempt to suppress 
fraud by inducing payment delays. Security in payment 
systems means minimiTing risk to a level acceptable to 
participants. Risk management in existing systems is accom- 
plished by varying combinations of technology, payment 

30 practices, insurance, education, laws, contracts, and enforce- 
ment The state of die art uses cryptographic technology, 
such as public-key cryptography, to support payments 
among parties who have no preexisthig relationship in a 
scalable maimer. 

35 Many existing cryptographic protocols, such as SSL (K. 
E B. Hickman, The SSL Protocol, Internet Draft <draft- 
hickman-netscape-ssl-(X).txt>, April 1995), SHTTP (E. 
Rescorla, A. Schiffinan, The Secure HyperText Transfer 
Protocol, Internet Draft <draft-rescorla-shttp-0.txt>, 

40 December 1994), PEM (J. linn, Privacy Enhancement for 
Internet Electronic Mall: Part I: Message Encryption and 
AuthenHcaHon Procedures, RFC 1421, February 1993), 
MOSS (S. Crocker, N. Freed, J. Galvin, MIME Object 
Security Services, Internet Draft <draft-ietf-pem-mime- 

45 08.txt>, March 1995), and IPSP (R. Atkinson, Security 
Architecture for the Internet Protocol, Internet Draft <draft- 
ietf-q)sec-arch-02.txt>, May 1995), provide security func- 
tions for pairwise communication. For exanq)le, SSL pro- 
vides privacy and authentication, but no non-repudiation, 

50 between clients and servers of application-layer protocols 
such as HTTP and FTP. Many payment systems involve 
three or more parties, i.e. buyer, seller, and bank. In such 
systems, certain types of risk can be ameliorated by sharing 
sensitive information only among a subset of the parties. For 

55 exanq)le, credit card fraud can be reduced by transmitting 
credit card account numbers between buyers and banks 
without revealing them to sellers. 

As the Internet continues to grow, a significant portion of 
the economy may become inextricably interwoven with 

^ Internet-based on-line transactions. It would therefore be 
advantageous to provide a secure, reliable, and efficient 
mechanism for in^lementing transactions associated with 
on-line commerce. 

g5 SUMMARY OF THE INVE^aION 

A courier electronic payment system provides customers, 
merchants, and banks witii a secure mechanism for using a 
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public network as a platform for credit card payment ser- protocol (11) is needed to provide such features as signature, 

vices. The system governs the relationship between a non-repudiation, and secondary encryption. The secondary 

Customer, Merchant and Acquirer Gateway to perform encryption term defines encryption of certain data fields for 

credit card purchases over such networks as the Internet The decryption by a third party, not necessarily the recipient of 
system uses a secure connection to simplify the problem of 5 the entire message. The payment protocol uses two secure 

latcmet-based financial transactions in accordance with an channels, one channel between the customer and the 

electronic payment protocol that secures credit card pay- merchant^ and the other channel between the merchant and 

ments and certifies infrastructure that is required to enable the acquirer or payment gateway. However, the payment 

ail of the parties to participate in the electronic commerce, specific financial messages communicated between the cus- 
as well as to provide the necessary formats and interfaces lo tomer and the merchant are protected as part of the payment 

between the difTerent modules and systems. protocol without assumptions for a secure channel 

BRIEF DESCRimON OF THE DRAWINGS '\t^'^:^ ^ »ndalymg secure 

ijivu^ i^M^^^r^ xxvA^ ixu^ i^r^wy ixyyjij trausport laycT for the followmg reasons: 

HG. 1 is a schematic representation of a transaction Simplify the payment protocol because node-to-node 

enterprise including flow diagram showing a payment pro- 15 authentication, privacy, and data integrity are automati- 

cessing protocol according to the invention; cally adiieved by the transport layw. This removes the 

HG.2 is a flow diagram showing a transaction according conditions of guaranteeing message integrity and pri- 

to the invention; vacy from the payment protocol. 

FIG. 3 is a flow diagram showing a capture protocol Separate connection encryption, authentication, and 

according to the invention; and integrity from the payment protocol provides for more 

FIG. 4 is a flow diagram showing a settlement protocol flexibility in supporting future secure Internet Protocol 

according to the invention. (IP) or similar mechanisms. 

DETAILED DESOOPnON OF THE . The secure transport layer supports data privacy and 

i>Fiiii^u.^^^Q^*v^4^i 1^ mtegnty for the commumcauons between any two nodes. 

iw liiMiiUW 25 This implies that two secure channels are setup, one channel 

The invention herein described implements a secure cou- between the customer and the merchant (12; FIG. 1) and the 
rier electronic payment system that provides customers, other channel between the merchant and the payment gate- 
merchants, and banks with a secure mechanism for using a way (14). Also, authentication of the appropriate nodes is a 
public network as a platform for credit card payment ser- function of the secure transport In particular, the payment 
vices. The described system governs the relationship protocol assumes the following properties of the underlying 
between the Customer, Merchant and Acquiring bank secure transport: 
(referred to herein as the Acquirer Gateway) to perform Privacy 

CTedit card purdiases securely over such networks as the AH channel communications between any two nodes in 

Internet The system uses a secure connection (transport) to the system should be encrypted. This guards against any 

sinq)lify the problem of Internet-based financial transac- network snooping and does not give any information to 

tions. possible attackers. 

The electronic payment protocol described herein is a Authentication 

three-, four-, or more-way conamunications protocol. The There are two distinct forms of authentication that need to 

primary parties are the Customer (buyer), the Merchant be addressed: 

(seller), and the payment gateway (representing the Acquir- First, all merchants and acquirers should be authenticated 

ing bank.) The issuing bank's involvement herein is to each other and to customers. Customer aulhentica- 

assumed to be through flie private networks in use by such tion is supported as an option, 

bank today. Because such private networks are weU under- Second, support for signature for proof of authorship and 

stood in the art the discussion herein does not address issues receipt for non-repudiation purposes may be necessary 

that are related to having the issuing bank attached to the fo^ some plications, 

Internet -The first form of authentication can be achieved by a 

The protocol herein described is used to secure credit card reliable secure transport mechanism. The second form must 

payments and to certify infrastructure that is required to access the fields and values that need to be signed, and 

enable all of the parties to participate in the electronic therefore should be performed in the application, 

conamerce by using the internet as well as to provide the Data Integrity 

necessary formats and interfaces between the different mod- Integrity is maintained at all times using a keyed message 

ules and systems. Hie system is designed to use the inter- digest computation. This should be a part of the channel 

active model of the World Wide Web in common use today security mechanisixL An extra layer of integrity is added to 

for client-server transactions on the Internet However, the the message level using a hash of eadi message to avoid 

preferred embodiment of the invention is applicable to other early termination type attacks, and to make sure that the 

delivery mechanisms, such as store-and-forward type messages acrive at the recipient unaltered, 

mechanisms. The payment protocol, on the other hand, is concerned 

Electronic Commerce Using Credit and Debit Cards with payment specific issues. These issues are outlined 

The following discussion outlines the security issues ^ below: 

involved in an electronic credit/debit card payment mecha- Confidentiality of the credit card number, PIN, and other 

nism using the Internet The security requirements can be customer information. These items are kept encrypted 

divided into two classes: with regard to aU parties, including the merchant han- 

connection (or channel) security, and dling the transaction. 

payment specific security. 65 Confidentiality of the specific order information from all 

Channel security can be provided by a secure transport parties other than the Merchant This includes, for 

layer (10; FIG. 1), while a higher layer electronic payment example the acquiring and issuing banks. 
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Digital signatures on the various messages communicated 
between the different parties to ensure authorship. It is 
important to point out that this is di£Ferent from node 
authentication because* in several cases, message 
authorship proof is needed between two parties that are 
not directly communicating with each other. 

Notation 

K{value}=value encrypted under K using a symmetric- 
key algorithm 

PKx{key}=key encrypted under the Public Key (PK) for 
X using a public-key algorithm, where x can be C for 
customer, M for Merchant or A for Acquirer. 

E{value}=encryption of value under a data encryption 
key that is encrypted under the public key of the 
recipient This construction is commonly referred to as 
a digital envelope. 

H(value)=The message digest of value using a negotiated 
message digest algorithm 

Cx, CEKTx^The certificate of entity x. 

Sx(Value)=The value combined with the digital signature 
of the entity x using its private key. The signature could 
be verified using the public key PKx from the certifi- 
cate Cx. If entity x does not have a public-private 
key-pair, then a low grade signature can be generated 
using a hash of the Value with some infcnnation from 
X, for exaiiq>le a credit card number, some personal 
information about x, such as social security number, 
billing address information, or a PIN. 

The protocol description herein applies to any account 
based payment medianism, with an emphasis on credit 
cards. Thus, the basic protocol also applies to other payment 
methods. 

Interactive Vs. Store-and-FOTward Design Methodologies 
The system described herein uses the advantages that an 
interactive environment provides to the customer and mer- 
chant. However, the basic scheme is usable for a store and 
forward mechanisms as well. An interactive environment, 
sudi as available using the World Wide Web, provides all 
parties with an immediate response that indicates the status 
of the messages communicated. An immediate acknowledge 
for the delivery of a payment message, for exan^le, pro- 
vides the customer with feedback as to the status of an order. 
Such facility is not available with a store-and-forward 
enviromnent It is considered important for a successful 
system to support state of the art mechanisms, such as the 
World Wide Web, because such system provides the user 
with an immediate feedback as to the status of the ord^, 
somewhat similar to a customer in the store payment modeL 
Protocol Design Requirements 

The following discussion describes the requirements that 
the electronic payment system has to satisfy to meet the 
Business requirements of electronic commerce. There are 
different requirements for each of the entities involved. The 
following sections describe the requirements of the payment 
jffotocol applications. The protocol presented herein is simi- 
lar to systems proposed by several other protocols from 
other vendors (see the discussion above), but supports a 
con^lete suite of credit/debit card transactions and uses a 
secure transport layer. The intention is to provide an 
efficient, secure protocol for processing payment transac- 
tions that is readily adopted by merchants and financial 
institutions. 

In general, the protocol also includes an acknowledge for 
each message to provide the message sender with feedback 
as to the status of the message. Thus, the sender is expected 
to resend a message if an acknowledge is not received within 
a specified period of time. 
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The Customer Application (16; FIG. 1), 

The customer possesses the following information: 

Personal Account (Credit Card) Number (PAN), billing 
address information, PIN for various accounts, and any 
other confidential information ^at may be required for 
authorization purposes. 

Name and shipping address information. 

Optionally, one or more digital certificates. 

A connection to a network, such as an interactive (World 
Wide Web for example) connection can exploit all of 
the features of the herein described systeia 

Customer Requirements 

Unauthorized entities should not have any access to 
transactions on the wire. 

The credit card information can be hidden from the 
merchant to prevent attacks on the Merchant's server 
by hackers on the Internet, as well as to prevent 
unauthorized charges by Merchants. 

Optional receq>ts signed by the merchant to allow the 
customer to obtain proof of the transaction. 

Prevention of unauthorized transactions, such as transac- 
tion replays by an attacker, modified transactions, or 
fake transactions. 

The customer application implements all of the browsing 
and shopping functions, as well as generating Purdiase 
Orders, payment information (PI), and signatures for trans- 
actions. Additional functions needed to support electronic 
credit card transactions are listed below: 

Receive price and product information from the merchant 
and encrypt the transaction ID supplied firom the mer- 
chant with the credit card number or other financial 
information. Ihis information is made accessible to the 
acquirer only using the acquirer's publio-key, which is 
extracted from the acquirer digital certificate. 

Verify signatures from the merdiant to ensure tiie origi- 
nation of messages. Make sure the Order as supplied in 
the receipt matches the original order generated by the 
customer earlier. 

Generate signatures on payment messages using an 
optional public key certificate. 

The Merchant application (18; HG. 1) 

The Merdiant possesses the following information: 

Merchant ID number (MID) assigned by the acquirer to 
each Merchant These MIDs may be globally unique or 
unique to a specific acquirer, depending on the in^le- 
mentation. 

Merchant name and address. 

Merchant digital certificate(s). 

Name and information about the Merchant's Acquirer(s), 
including the Acquirer's financial certificate and infor- 
mation about how to communicate with the Acquirer's 
Gateway. 

A database of all open transactions with corresponding 
Transaction IDs and AuthlDs with customer informa- 
tion. 

Merchant Requirements 

Efficient and automated operation of payment authoriza- 
tion and capture through the Internet or using existmg 
internal c^ture systems. 
Authenticated (signed) authorization and capture 

responses from the acquirer. 
The Merchant's application provides all the server func- 
tions for the customers to obtain product information and 
pricing. It also serves as an intermediate between the cus- 
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tomer and the acquirer. The merchant application should PIN 
also include the following to allow performance of aedit Billing address 
card transactions: Shipping Address 
Generate a transaction ID for each customer order. The Resp-Code: Response code from the authentication pro- 
transaction IDs are generated sequentially and used ^ qq^^ 

'^^y^^^^ '^'^''^^'^?'^^^ Auth-Code: A 6^git number returned by the banking 

until It has been authorized by the acquirer. ^^^^^ clearing/capture steps. 

Verify the acquirer signature on capture responses and the icdata 

customer signature on receipts. o*,r»^A ^.**u 

* 10 CaptureResp: A response for the capture process. 

Generate receipts for customer signature optionally. ^^^^ ^^^^^^^ ^ ^ 

Generate digests of order information for the acquirer to j^^^^ ^ 

verify authenticity of the purchase orden ^ tn. ^ n- ^ j. . i • ^ ^ ^ . 

The Acquirer (Gateway) AppUcation (20; FIG. 1) ^ Signature: A digitd ^gnature as defined m this 

The Acquirer possesses the foUowing information: . 15 ^<'<'^^^ ^^^^ followmg: 

Acquirer name and address. SIGNx(data)=Si(data. nonce, datcX nonce, date, signer's ccrtifi- 

Acquirer digital certificate. 

Names and infcHmation. including certificates, about the The above format ensures that all signatures are fresh and 

Merchants that arc signed up with the Acquirer. This dated Providing the certificates with the signatures simpli- 

can be implemented as a database of merchants stored ^ fies the exchange of the certificates, 

encrypted on the gateway machine. Message Flow and Definition 

A table with each merchant's current open Transaction The protocol described below assumes that merchants and 

, IDs and corresponding AuthlDs tagged with each mer- credit card acquirers possess digital certificates. The client 

chant' s MID. 25 (customer) may possess one or more d^ital certificates as an 

Acquirer's Requirements option. 

Support for different methods of managing transactions, protocol divides the needed operations into a set of 

one time, recurring, and partial shipment included. ^^^ic protocols that are described first. The foUowing dis- 

Authenticated transactions by signed-up merchants. ^^"^^^^'^ r '^^^'^7 ^^I" financial transaction is 

Hieacquirerapplicationistj^ic^yanadditiontoasetof 30 accomplished. All protocols support full privacy, 

products thai are needed to coi^lete financial transactions non-repudiauon, and mtegnty. The underly- 

+h» T„t-™-t o«o.i:,.J7o««ii««t.-«« « ing Session layer provides all connection secunty functions, 

over the Internet The acquirer application performs the ^ . ^. ^ j • ^ ^ 

foUowing functions- ^ ^ cg.pnvacy, authentication, andmtegnty, from the channel's 

point of view. Any document or field (data element) level 

Receive order amount and Transaction ID with customer operations are preferably performed at the appHca- 

financial information and perform credit card authori- 3^ xevd. 

^tio*is. -pfjg contents of each message depend on the actual 

Receive capture requests and perform capture confirma- opwation (purchase, return, etc. ... ) perfOTmed Therefore, 

^ tion. these contents are discussed under each operation section 

Translate a standard message format from the Merchant ^ below, 

into the proper formats used by the existing authoriza- The protocols outlined below start as the customer is 

tion network (40; FIG. 1). ready to purchase some items from the merchant using a 

The Credit Card Based Electronic Commerce Payment credit card. It is assumed that the customer is already 

Protocol finished with his shopping and has made the decision to 

Message Definitions purchase something. 

This foUowing discussion outlines and defines aU the The customer sends a message (19; FIG. 1) to the mer- 

needed quantities and message components for the messages chant requesting a price quote for the items of choice before 

used in the payment protocol: the payment instruction message start > 

PAN: The personal account number for the card holder. and Time fields in aU the foUowing messages are 

NormaUy this is a credit card number. 50 "^^^^^ attached by the node creating the message. This 

Expiration Date: The 5 digit expiration date of the card "^^^""^ ^""^^^^ ^ ^"^^ ""^"^ 

, , ^ ^ o- I- freshness of the transaction. 

Merchant ro: A unique number for each merchant capture and settlement groups desoibcd below can 

assigned by the acquirer signmg up the merchant. Tlie replace modem methods, that use lease lines or private 
merchant ID is unique for each acquirer, and thus networks, without disrupting the protocol. This enables 

includes the acquire ID as part of it to generate a 55 different aequiras to implement portions of the protocol in 
g^obaUy unique number. The aoquirerlD IS assigned by s^ps, while maintaining backwards compatibility with 
the a^d assocmtions and is not transmitted alone as v^^ting systems throughout the phase-in ^ocess. Initial 
part of this system. implementations do not have to implement those sections. 

Transaction ID: A unique number assigned by the mer- Each Secure Courier message 19 includes two parts:' 

chant for each transaction. The merchant and the card " message wrapper (30; HG. 1). and 
holder can use this number in conjunction with the ^ 

merchant ID to identify any particular transaction. j^^^ ^ ^^^^^ ^^^^^ ^ 

Acquirer Ceitificate described below. The message wrapper consists of the 

Merchant Certificate ^ following elements: 
Total Amount Order Number, and 

H(Order) routing information. 
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Each of the messages bdow consists of two parts. The Pt C-^M 

forward part is desoibed in detail for each message, while ^ ^he PImessage is a signed message from the Card Holder 

an optional acknowledge is generated by the reapient and descSbed below 

sent to the sender to ensure the receipt of the message. The su ucaoioca ociow. 

acknowledge is a hash of the message, which actually proves 5 ^ 

the receipt by the appropriate recipient because of the use of' Version, current date, expiration date (Validity Period), 

the SSL layer that guarantees an authenticated channel. The Total Amount, Currency, Orderhash, MerAcqHash, 

time of receipt is concatenated to the hash and the concat- Credit Card information (Cardlhfo). 

enated message is used as an acknowledge. where- 
in addition, each message is considered to be expired if it 



is received after the message's validity period is over. ^° Qrdei^Hash of the order description including any salt for 

To authenticate further the acknowledge messages, a minimizing attacks on the hash, 

digital signature can be used instead of a hash and tiie time MerAcqhash=hash of the merchant ID, transaction ID and 

stamp. If the ongmal message has expired, then a denial IS ^♦w «.«.^k««*^,™„,wj * t-u- ^ ♦ • . 

received instead^d the sender is asked to repeat the otoer merdumt or acquis 

operation. 15 the merchant-acquirer pair and is not needed by the 

In an authorization group (see FIG. 1) consisting of a ^^y^ ^han for inclusion in the PI message, 

customer C, a merchant and a (jateway G, a transaction CardInfo=(Personal account number (PAN, eviration 

(FIGS. 2 and 3) that includes the Purchase-Order, Payment date, other optional information that may be needed by 

Insdruction (P^ message below causes the Merchant to the payment processor/acquirer, 

respond with: 20 pj |s preferably sent encrypted to die Acquirer using 

Sj«(H(Puicha«,-Oid(ir.Pl),l)ate.T^^^ (1) Acquirer's pubUc key. In some cases, due to certain 

Merchant - Acquirer relationships, tiie PI may be sent in the 

Tte Offerpieferably has an expiration date beyond wMch dear. Jt is always recommended to encrypt the H message 

Due to the use of a secure transport layer, the Transaction E(siip)=PKA{DES key K} K(Slip) 
ID (l^dD) is used for book keeping purposes and optionally 

to preventMCTchants from replaying authorization requests, ^ ^^^^ 

It is assumed that merchants have signed up with this service ^ 

and that they are trusted to some extent The PI value should an „ . 

be encrypted so that the Merchant's server, e.g. on the ei=signa(B(sup)) 

Internet docs not have any clear credit card numbers that ^ ^ . . . ^ . 

can be accessed remotely. .. where the SIGN operation is defined as above. 

The TxID is combined with the aedit card information It niay be necessary to send the PI without encryption in 

and encrypted in the PI message. This ensures that each case of a merchant that performs the capture process inde- 

message is different if the Merchant uses a unique TxID for pendenUy. This is reflected in a capability field in the 

each transaction. It may be diffiailt for the Gateway to track machant certificate that instructs the acquirer software to 

the sequence numbers for the TxIDs issued by any particular send the credit card information back to the merdiant As 

Merchant because they arrive out of sequence, in general, discussed above, the data on the channel are encrypted by 

depending on the customer's response time to the Offer from the secure transport, and the Merdiant is the only entity that 

themerchantpriortothebeginningoftiiepaymentprotocoL 40 may receive the dear H data from the acquirer. Normally, a 

Tlie Purchase-Order should be recewed by the Merdiant ^ordiant with a good history could be considered trustwor- 

paor to tiie expiration tmie of the Ofc. j^y and can obtain clear account numbers from the acquirer. 

Messages can indude a hash of all the message parts to ^ 

add a levd of integrity at the application level This provides The PI can be sent m several forms usmg, for example fiie 

therecipientof a message with an extra degree of confidence 45 ^^^^ ^ fonnats. These formats include: (unencrypted) 

that the complete unaltered message has been received. This content, encrypted, signed, enveloped, and signed and envel- 

hash can be induded as part of a Secure Courier Message oped. The choice depends on the capabilities of the user and 

Wrapper that is described bdow. the navigator configurations. The payment gateway can 

A receipt is then issued at this stage if the authorization decode any of these formats using the PACS handler. The 

request was combined with a Capture operation. 50 recommended dioice is the enveloped format described 

The data needed by the dient before the payment protocol above, 

starts are described below as part of the Offer message, Order-Inquiry; C->M 

These are usually communicated at the final stage of the Oate, (order number or MTO, TxID), Orderhash. A hash of 

sho^mg and negotiation stages. ^ ^^^^^ components is added. Orderhash is the 

c^^,^;v^7ir^. T. . . T r*. u . . hash of the Purchase-Order and is used by the gateway 

SIGNM(Validity Paiod, Iteins, Payment Method, zip ^o compare with the Orderhash value computed by die 

code or country (for shiiymgdiarges^ Merdiant to verify the correctness of fte Purchase 

Am(mnt, Om^cy Mediant ID (>m)X Acquirer's Order without actually having access to the details of 

^ certificate (CEKTA), and transaction ID (TxID)). tiie order. 

TTie message is s^ed by tiie Merdiant 60 This message is sent by tiie customer to the Merchant, at 

nie inirdiase-Order and the Payment Insmiction mes- ^ request the current status of tfie order. Hie 

sages bdow are sent togetiier from the Card Holder to the possUt responses are: 

Merchant ^ * 1 1 j ^ 

Purdiase-Order: C^M Order-Admowledged; 

Name, VaUdity Period. Items, Total Amount, Currency. 65 Authorization-completed; 

Merchant ID (MID), transaction ID (TxID), and ship- Goods-Shipped; or 

ping address. Account-Billed, 



(2) 



(3) 
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These responses are communicated to the customer using 
the Order-Status message. 
Order-Status: M-»C 

(Resp-Code, Auth-Code translated to language that the 
user can understand). Date, Tune, (Order number or 
MID, TxID), Orderhash. 

The Order-Status provides an acknowledge for the Order- 
Inquiry message. This message is implemented to provide 
the customer with a status on the order. Resp-Code and 
Auth-Code may be translated to the customer to understand 
the exact status of the order as listed in the Order-Inquiiy 
above. 

Autij-Rcquest: M->G 

SIGNM(MerchantInfo including MID, TxID, Validity 
Period, Total Amount, Orderhash, Auth-Capture, PI, 
payment method, batch sequence, optional invoice.) 

Auth-Response: G-J-M 

SA(Auth-Code, Date, Time, Current Amount, Orderhash, 
MID, TxID, optional PI for Capture through a different 
site). The Auth-Response also provides an acknowl- 
edge for the Auth-Request message. 
Auth-Capture is a flag which is set if the Merchant is 
Cq)ture the transaction at the time of authorization. Auth- 
Code is used as a transaction identifier for the above 
Order-Inquiry and Order-Status messages. The Acquira**s 
signature is attached in the case the Merchant needs to prove 
that the authentication response actually came from the 
Acquirer. 
Receipt: M->C 

SM (Cq>tureResp, Auth-Code, Validity Period, MID, 
TxID. amount. Order) 

The receipt guarantees the Customs that the Merchant 
has committed to shipping the goods at the prices quoted and 
that the payment has been authorized the bank. The 
acquirer signature is optional and depends on the particular 
rules set for electronic commerce. 

The Receipt transaction can be implemented using a 
notification message, for example using an email message 
from the Merchant to the Customer, to retrieve the receipt 
information from a particular location on the Merdiant*s 
server. 

Capture Group 

A separate Capture transaction is necessary for the cases 
that require delayed time for payment from the authorization 
such as hotel and car rental transactions. If is also necessary 
when a customer's signature on a transaction receipt is 
required. Therefore, the protocol always assumes a separate 
capture transaction from the Merdiant to the Gateway (see 
HG. 1). 

This portion of the protocol starts when the merchant is 
ready to ship the merchandise and/or charge the customer 
(see HG. 4). 

Capture-Request: M-»G 

Auth-Code, Validity Period, Orderhash, amount, MED, 
TxID. E(PI). 

A Capture request does not suffer from a replay attack as 
with an authorization request because a capture request is 
attached to a particular AuthID that can only be exercised 
once. 

Capture-Response: G-^M 

CaptureResp, Validity Period, Orderhash, amount, MID, 
'WD. 

The message is signed by the acquirer as an acknowledge 
of the Capture-Request message. 

The returned CaptureResp=-l if unsuccessful, successful 
if any other value is returned. 
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Settlement and batch processing 
It is expected that settlement may be performed in a 
variety of ways that may not involve the Internet. See FIGS, 
1 and 5 in connection with the following. 
5 Settlement-Request: 

TotalAmount, MID, Date. 
Settlement-Confirm: 
SetticmentCode, Action. 

SettlementCode=-l if the amount rq)orted by the Mer- 
jo chant is not valid, valid otherwise. If -1 is returned, then the 
Merchant sends all AuthlDs with amount to the Acquirer 
until the difference is reconciled. Different policies may be 
applied by different acquirers to resolve these situations. 

An Open-Batdi message can be used by the Merchant to 
precede all Capture requests. A Qose-Batch has to be sent 
at the end of the batch. More details on the batch processing 
features of Secure Courier are provided below. 

Error Recovery 

The following discussion addresses issues related to 
recovery from error conditions, generally from messages 
20 that have not been correctly delivered. Each portion of the 
protocol assumes that the previous sequence of messages 
have been completed and reached the intended recipients. 
Error recovery is achieved by a two step process: 
In the first step, the sender of a message repeats the 
25 message if an adaiowledge is not received. There are two 
cases to be considered here: 
if the original message was actually received then the 

recipient repeats sending the acknowledge, 
otherwise the message is considered as new by the 
30 recipient and the appropriate action is taken. 

The second step occurs when an acknowledge is not 
received after the message has expired. In this case, the 
transaction that generated the message has to be restarted. 
Examples of error recovery are presented below. More 
35 details on error recovery for each of the Secure Courier 
message step are set forth below. 
Errors in the Authorization Process 
If the Auth-Response is not received by the merdiant 
within a certain time frame, the Merchant repeats the process 
40 by sending the Auth-Request again if it has not expired yet 
The Gateway responds with an Auth-Response. If the origi- 
nal Auth-Request was not received by the Gateway, then the 
message is sent to the bank. Otherwise, if this is a repeated 
message, only an Auth-Response is sent to the Merchant If 
45 the original Auth-Request has expired, then the Mcxdiant 
should consider the transaction invalid and should reissue 
the Offer with a new TxID, The same TxID should not be 
used more than once. A message to the gateway indicating 
that action may need to be sent 
50 Errors in the Capture Process 

The same system works here as described above for the 
Authorization phase. If the Capture-Request message has 
expired and the Capture-Confirm does not reach the Mer- 
chant within a reasonable period of time, then the transaction 
55 should be considered invalid and the conq)lete transaction 
sequence should be redone. 

Errors in Receipt Delivery 
( If the Signed-Receipt message does reach the Merchant 
. within a reasonable period of time, then another Receipt is 
60 sent. It the Receipt message has expired, then the transaction 
should be reversed, using another sequence of steps with a 
negative amount. This is only done if a receipt is mandatory 
according to the implementation. 
Purchasing 

65 The following discussion describes the purchasing pro- 
cess. T\vo different scenarios are possible, one for immedi- 
ately delivered products and the other for delayed ddivexy. 
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Immediate Delivery of Goods able. la diis case, the merchant should actually peiform a 
There is no differentiation here between immediate or separate authorization for each partially shipped portion of 
delayed delivery to simplify the protocol. The Capture the order. This can dtiier be perfonned by sending the 
messages are separate from the Auth messages to enable the . Auth-Request message for each partial shipment, or by 
protocol to support all types of goods delivery. 5 performing multiple Capture-Requests for a single Auth- 
The customer finishes shopping and browsing the mer- Request This is typically dictated by the Acquirer's soft- 
chant's mall, news-stand, or cyber store. A coEection of ware capabiUties, which differs greatly between acquirers, 
items arc kept in a shopping cart for price quotes. Once the Sf . 

customer chooses the payment option, a secure transport . ThefoUowmg discussion descnbes the process of return- 

chamiel is estabHshed and the nodes exchange certificates, lo "^gi^ejdiandise. Each merchant needs t^ 

TK»o- ^-rf;fi^of»c o„o,-ioKi« f« policy bccausc some merchandise can be non-returnable. If 

-niese certificates are made available to the payment proto- /^^^^ merchandise, the following 

coiiayers. * u . *u sequence of messages is performed: 

The customer scn^ the list of items to purchase to the ^h^ ^^^^^ presents the merchant with returned ma- 
merchant, includmg the type of payment method The cus- chandise and is asked to present the credit card electroni- 
tomer's appHcation needs to specify which type of aedit 15 cally The merchant sends an Offer message to the customer 
card is used to allow the merchant to supply the correct ^ith a negative amount representing a return. The custom- 
Acquirer's certificate. The merchant replies by sending an er's application computes and sends a Purchase-Order, 
Offer message, including price quotes. A transaction ID including the Payment Instruction FI message with negative 
sequence number is issued to the customer. amounts. The merchant sends a c^ture request message 
The customer's application prepares the Purchase-Order 20 with the negative amount and the customer's account is 
and PI messages using a credit card number. The merchant's credited if the transaction is verified to be authentic. The 
application includes a time out mechanism to define an acquirer keeps records of transactions to verify authenticity 
interval within which the customo^ must reply, otherwise the of return transactions. The Gateway communicates the 
offer is invalid and the transaction ID may be reused. This Acquirer's decision regarding the return back to the Mer- 
is done to protect special prices that the merchant establishes 25 chant The m^chant signs all capture requests to prevent 
for limited periods of time. The merchant receives the Order customers from fraudulent returns, 
and E(Pi), prepares the H(Order) message, and sends to the Disputes and Charge-Backs 

Acquirer with the PI for authorization. The Auth-Request The following discussion describes the process of disput- 

may cause an immediate Capture transaction if the Merdiant ing charges. Electronic authorization and receq}ts reduce tlie 

is ready to ship the merchandise at Auth time, or if a 6dbit 30 risk of mischarging a card. However, under some 

card transaction is being perfonned. circumstances, a customer may dispute a particular charge 

The Acquirer checks the correctness Of the Order and PI and can request a refund. A signed receipt from the customer 
fields and performs an authorization for the required could be grounds for denying the refund, but some acquirer- 
amount. If successful, the Acquirer returns a signed message merchant pairs do not require receipts. A charge dispute may 
that includes fiie Authorization ID. If not successful, a denial 35 be resolved using the following sequence: 
code is sent In any case, the merchant's transaction ID is The customer usually communicates directly wi& the 
incremented. card issuer in the case that they have been over charged or 

The merchant receives the authorization ID that may be erroneously charged. All parties reproduce the applicable 

forwarded to the Customer for proof of authorization. For signatures on the messages throughout the transaction for 

inmiediate delivery, the goods are shipped and the funds are 40 the Acquirer to be able to settle the dispute, 

transferred between accounts using the banks network. The Enhancements 

merchant sends a settlement message at the end of the day The Gateway may possess several certificates for corn- 
using a settlement request message. municating with different Merchants and for different pur- 
Delayed Delivery of Goods poses. This can help hide the identity of the payment 
In the case where the merchant has to ship the goods at a 4S processor, if required. Also, different certificates for signa- 
later time, the following scenario is used: tures and encryption m^ be used for export compliance 

After the initial steps are completed, the authorization purposes, 

request (with no Capture option) is sent to the gateway. Hie A single digital signature may be generated by any entity 

sequence of Capture messages are sent to the gateway only for multiple messages by concatenating the hashes of mul- 

when the merchant is ready to ship the product. The remain- 50 tiple messages and then signing the entire combined hash, 

der of the protocol is the same as described above for the This proves that all messages have been received. For 

immediate delivery of goods case. exanq)le, the Merchant may combine many Hashes from 

Subscription-Based Payments many customers and provide one signature. This inqiroves 

In some cases, the merchant is allowed to periodically, the perfonnance because the signing process is the most 

e.g. every month, send authorization requests based on an 55 expensive operation in the entire protocol, 

agreement with the customer at the begiiming of the sub- Export Control 

scription period. In this case, the merchant can request the The export issues with the use of cryptography in com- 

customer to send multiple Pis with the Purchase-Order and merdal systems is of particular in^)ortance with financial 

submit each PI at the time of each installment. Alternatively, transactions on public networks. The following discussion 

this can be done using the unencrypted FI in the above 60 describes the different issues and requirements of interna- 

protocol so that the merchant can produce all the needed tional financial applications across public networks. In 

components. The merchant has access to die clear aedit card general, RSA and DES have been approved for export and 

information. used for authentication and encryption of financial data 

Partial Shipments purposes, respectively. 

The case of a partial shipment is somewhat similar to the 65 Selective Strong Encryption for Financial Data 

subscription based payment, except that the merchant may The data conomunicated between the different nodes on 

not now ahead of time when certain merchandise is avail- the Internet include a variety of sensitive financial 
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infomiatioD. as weU as other product and order information. 
It noay be acceptable to encrypt the bulk of the data using one 
of the algorithms currently approved for export, however, 
the financial data should be protected at an acceptable level 
for the banking industry regardless of the geographical 
location. This may also be implemented on top of the bulk 
encryption for other data streams or as a replacement for the 
undemcath bulk encryption. 
Third-Party (Secondary) Encryption for Selected Data 
There is a need within a message to encrypt infcnnation 
that is intended for a secondary node. For example* encrypt- 
ing the CTedit card information to a service provider embed- 
ded in a message sent to a merchant A preferred way of 
achieving this functionality is to apply encryption at two 
different layers of the Internet network model. An individual 
Held encryption can be accomplished at an application layer, 
while the channel encryption can still be applied to the entire 
record that the socket layer receives. 

Strong Merchant and Acquirer Certificate for Signature 
Computation 

The following is a list of digital certificates used for 
multiple purposes in a commercial application over the 
Internet: 

Authenticating the channel between a client and a server. 

Encrypting data from one node to another through other 25 
nodes, lypically the DBS keys are encrypted using the 
recipient's public key and the bulk data is encrypted 
Using the DES keys to form a digital envelope. 

Signing a message or a receipt for non-repudiation. 

It is clear that the last item above requires a certiiicate 
with a larger key size for non-repudiation, the first two items 
could be relaxed for export purposes since they could be 
changed periodically. This does introduce a synchronization 
problem in distributing and using certificates. One solution 
provides for the acquirer/issuer bank to issue digital certifi- 
cates that overlap in their validity periods. During this period 
the use of either certificate makes for a valid signature. In 
fact, the acquirer's financial certificate system is designed to 
be short term oriented, so that revocation issues can be 
avoided. This also makes the export issue with Acquirer's 
certificates less of an issue. 

Infrastmcture and Certification for Electronic Commerce 

The following discussion describes the details of the 
certification and infrastructure for electronic commerce on 
the internet cr other public networks: 

The Certification Hierarchy 

The invention uses a number of hia:archies that are 
administered by the card associations or their affiliates. It is 
necessary that the card associations (brand names) are (or 
administer) the roots of these hierarchies. There are sq)arate 
hierarchies for issuing bank, merchant, and consumer cer- 
tificates. Oedit card processors also receive certificates that 
are equivalent to bank certificates. 

Example 

This following example illustrates how the system herein 
works in conjunction with MasterCard certification services. 
The interface between the MasterCard certificate and vari- 
ous buyer and merchant software is described later in this 
document. 

Certificate Trust and Formats for Different Entities 
The different certificates issued to the different entities 
acmally carry different meanings that are explained here: 
The consumer certificate (21; FIG. 1) is a signed message 
that verifies the right of the person named in the 
certificate to use an account. Note that there is no 
particular need to validate the authenticity of the name 
of the consumer as long as some appropriate evidence 
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of the right to use the account is presented. The signing 
authority can request information such as billing 
address and mothers maiden name to verify such evi- 
dence. 

The merchant certificate. (22; FIG. 1) is an identity based 
certificate that assures the right of the Merchant to use 
the supplied name for business. 

The certificate is usually issued by the acquiring bank that 
signed up the Merchant. 

The acquirer certificate (23; FIG. 1) is a special purpose 
certificate that is provided to the merchants and con- 
sumers to communicate securely with the acquiring 
bank and to verify signatures by the bank. The acquir- 
ing bankmay also receive a certificate issuing key if the 
acquirer is approved for issuing certificates for mer- 
chants. 

All certificates are encoded, for example as x.509 v3 
formatted certificates with the corresponding extensions. 
Buyer/Card Holder Certificate 

The consuma* certificate consists of the following fields. 
A consumer generally receives multiple certificates, each 
associated with a particular account The same key pair may 
be used in conjunction with more than one account 
Name, includes the following sections: 
Requester name, bank association name, issuing authority 
name, and an account ID which can be represented by 
Hash (account number, randomizing factor, billing 
address, mother's maiden name (optional)); 
Starting date for the validity of the certificate; 
Ending date for the validity of the certificate; 
Certificate serial number, 
Signature of the issuing authority; 
Public key for signatures/key exchange; 
Certificate type, for example signature only; 
Certificate authority policy ID, for exanq)le URL for 

policy location. 
Merchant Certificate 

The merchant certificate consists of the following fields. 
A merchant can obtain more than one certificate, one for 
each acquirer. A merchant with multiple physical locations 
should generate a different key pair for each location. All 
merchant certificates are directiy issued by die acquiring 
bank or the authority that the acquiring bank designates to 
issue merchant certificates: 

Name, which includes the following sections: 
Business or merchant name and address, Card associa- 
tion name, certification authority name, merchant- 
acquirer unique ID. 

Starting date for the validity of the certificate; 

Ending date for the validity of the certificate; 

Certificate serial number, 

Signature of the issuing authority; 

Merchant capabilities; 

Type of certificate; 

Certification policy ID; 

Public key for signatures/key exchange. 

The m^chant would then require different certificates 
from different acquirers if the merchant chooses to do 
business with multiple acquirers. 

Acquire Certificate(s) 

The acquirer possesses one or more certificates that 
perform the functions of financial transactions (PI message 
encryption), as well as signature operations for authentica- 
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tion responses. The acquirer's financial certificate consists 
of the following fields. The acquiring bank generally obtains 
several certificates. A discussion of this is provided herein in 
connection with the description of availability of the pay- 
ment services: 
Name which includes the following: 
Bank or processor name and address, card association 
name, acquirer unique number, certification author- 
ity name. 

Starting date for the validity of the certificate; 
Ending date for the validity of the certificate; 
Certificate serial number; 
Signature of the issuing authority; 
Certification Policy ID; 
Type of certificate; 
Public key. 

It is recommended that the acquirer possess one or more 
financial certificates, as well a different signature certificate. 
The financial certificate is conmiunicated to Merchants and 
Card holden for encryption of the PI messages. T avoid 
supporting revocation services for the financial certificates, 
it is recommended that Ifae financial certificate be valid for 
a short period of time, e.g. on the order of 1 day-1 week, with 
automatic renewal. The card holders and merchants then do 
not have to check for a revocation status. The signature 
certificate, however, is issued to be valid for long periods of 
time for Merchants to verify signatures on authentication 
responses. 

Sign-Up Processes 

To establish the infrastructure needed for the electronic 
payment system to function, all entities should sign-up widi 
the appropriate service and obtain the ^propriate certificate 
from the certification authority. 

Card Holder Sign-Up 

The consumer performs the following stq)s to sign-up 
with the service: 

The consumer invokes a URL to access the financial 
certification services. The consumer receives a form describ- 
ing the available account types for this service and then 
diooses the account type for whidi they wish to create a 
certificate. A form is downloaded from the certification 
service with the fields needed for the chosen account type. 
The card holder then fills in the necessary fields, generates 
the key pair and submits the form to the certification 
authority. The certificate is installed in the client ^plication 
upon receipt of die approved signed certificate. 

Merchant Sign-Up 

The merchant performs the following steps to sign-up as 
a merchant in the electronic commerce space: 

A merchant is signed up with an acquiring bank. In 
general, a contractual relationship is written between the 
merchant and the bank detailing the services supported by 
the bank. For exan^le, a merchant may obtain authentica- 
tion services only or authentication and clearing services. 
The exact rate charged by the payment service is also 
covered in the contract. 

In case the acquiring bank is also a certification issuing 
authority, the merchant produces the appropriate business 
practice papers and obtains a certificate firom the bank. 
Otherwise, the merchant obtains the certificate from the 
issuing authority designated by the acquiring bank. Each 
branch or location of the merchant obtains a certificate 
(optionally) in the same manner discussed above. The cer- 
tificate signing request includes then the branch name and 
location. 
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Acquirer Sign-Up 

The acquirer has different options as to how to enter the 
electronic commerce space. The first option is to obtain the 
capability to sign-up merchants, while the second option 
5 only allows an acquirer to process payments. In any case, die 
acquirer generally is acquiring merchants, and providing 
acquirer ceitificate(s) to the merchants. 

An acquiring bank signs up using the following proce- 
dure: 

10 A key pair of the appropriate length is generated, where 
more than one certificate is needed for the acquirer. In 
particular a financial certificate for key exchange and a 
signature certificate are needed. The acquirer's ofSdal rqv 
resentative should appear in person with the necessary 

15 papers at a certification autiiority approved by the card 
associations. Proof of business and other of&dal papers is 
typically required. The certification authority generates the 
appropriate certificate. An acquirer signature certificate may 
be given certification authority capability if appropriate. 

20 . Expired Keys 

a key expires, a renewal is needed for continuation of 
service. A new CSR is submitted to the same address used 
previously for obtaining a certificate to get a new certificate. 
The two certificate are allowed to overlap in validity periods 

25 for one day in order to avoid problems with different time 
zones. A new key may be required for a new certificate 
depending on the policy set by the certification authority. 
Compromised Keys 

A compromised key needs special attention as a special 
30 case for a revocation reason. Hie time of revocation is an 
inq^ortant factor to take into consideration in verifying 
signatures or validity of account numbers. A buyer's com- 
promised key should be dealt with as a stolen credit card. A 
compromised merchant's key should be reported to the 
35 certification authority and the appropriate acquirer to get a 
newly issued certificate, and register the conqnromised key 
as invalid for further transactions. The compromised mer- 
chant key is listed in a CRL maintained by the acquirer for 
verification of the validity of the merchant. 
40 A conq^romised acquirer key (for signatures only) is to be 
treated very carefully. Such an event has specific policy 
statements by the acquirer or the card association for recov- 
ery. The same applies for a compromised CA key. 
Revoked Keys 

45 A certificate can be revoked by the certificate owner, by 
the bank witii the associated account, or by the authority that 
signed the certificate. A card holder can revoke their own 
certificate under the following conditions: 
The consumer would like to dose a certain account; 
The consumer or merchant learned or suspects that their 

key is compromised. 
A merchant can revoke their own certificate in the fol- 
lowing circumstances: 

A merchant is dosing a certain branch or getting out of 
business. This is kept in a list at the acquirer for 
checking the merchant key validity. 
A bank may revoke a card holder's certificate for the 
following reasons: 
60 An account is over charged or does not have enough funds 
and should be suspended. A new certificate is issued if 
the account condition is ir]q>roved. 
A bank can revoke a merchant's certificate under the 
following conditions: 
65 The merchant has been conducting unapproved business. 
A revoked merchant certificate is added to a CRL main- 
tained by the acquirer for checking the validity of the 
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merchant. The user does not need access to the CRL because 
the payment cannot be approved without the acquirer's 
^proval. 

Consumas may also choose to obtain a CRL or check the 
revocation status of a merdiant's certificate under any 
condition defined by the card associations. 

Payment Service Availability Issues 

The general design of the system supports multiple loca- 
tions for the acquiring gateway. As a general rule, for 
security reasons, the same key pair should never be used by 
multiple Locations or by multiple machines. Therefore, a 
merchant needs to use some method of deciding which 
acquirer certificate to use. 

Which Acquirer Certificate Should the Merchant Supply 
to the Customer? 

The merchant obtains an acquirer certificate on a regular 
basis for use with card holder transactions, which is refeired 
to as the financial certificate within this document. This 
certificate has a short term validity period to avoid revoca- 
tion issues. This certificate is sent to the card holder as part 
of the Offer message described above. Note that this con- 
dition dictates that the merchant certificate is not in any way 
bound to the acquirer's financial certificate or key. 

Resolution of Down Service Condition at a Specific 
Location 

It is expected that an acquirer has multiple gateways for 
availability and load sharing reasons. These gateways may 
not have the same public/private key pairs and thus, the 
merchant may need to obtain several acquirer financial keys 
for different locations. If one of the acquirer gateways 
experiences some down time, the merchant should be able to 
select an acquirer key for a functional gateway within a short 
time frame. 

Distribution of Certificates 

Communicating Merchant Certificates to Customers 

A merchant certificate is communicated to the consumer 
or the acquirer as part of the signature. An alternative is to 
supply the mer^ant certificate in the authentication portion 
of establishing the secure transport and communicate the 
certificate to the applications layer of the merchant software. 

Acquirer Certificates Distribution Issues 

The Acquirer's financial certificate (short term) is com- 
municated to the merchant's every time they are renewed, 
for example at the beginning of every business day or week. 
These certificates are then conmiunicated to the buyers as 
part of the OflFcr. The merchant chooses the appropriate 
acquirer certificate to submit to the buyer depending on the 
rules. Acquirers' signature certificates are communicated to 
the merchants using the same mechanism described above 
for communicating the merchant's certificate. 

Distributing Buyers' Certificates 

The buyers certificates are distributed in the same manner 
as the merchant's certificate described above. 

The Interface to On-line Certification Service 

The following discussion describes the mechanics of 
providing certification services for a World Wide Web client 
There are two extensions that are presently preferred for the 
Buyer's Navigator to support user key and certificate gen- 
eration and installation. The implementation implies that a 
WWW client (Navigator) software includes a link to a page 
that lists the approved CAs and their URL locations. An 
access to such a URL presents the user with choices of 
certificate types supported by the specific CA. A form is then 
downloaded to the client for the user to input the necessary 
fields, generate the public/private key pair and submit the 
certification request to the CA. 

The following subsections provide some details for a 
WWW client to support on-line certification services: 
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Key Generation 

An HTML tag facilitates generation of key materiaL and 
submission of the public key as part of an HTML form. The 
new tag is: 

KEYGEN NAME="iiaine 

The KBYGENtag is only valid within an HTTMLform It 
causes the client user interface to provide for the selection of 
the key size for the user. The UI for the selection may be, for 
10 example a menu or radio buttons. The Navigator may 
present several possible key sizes. Currentiy the preferred 
export version only allows a 512 hit key, while the preferred 
US version gives the user the option of a 512 bit, 768 bit, and 
1024 bit key. A longer key size for export versions for use 
in signature operations only (no key exchange) may pro- 
vided. 

When the submit button is pressed in the client software, 
a key pair of the selected size is geuCTated. The private key 
is encrypted and stored in the local key database. The public 
^ key is extracted, DER encoded, and base 64 (RFC1113) 
encoded. The key data is DER encoded as a PACS #1 
RSAPubUcKey. This may be changed to SubjectPublicKey- 
Info as described in PKCS#7. Finally, the form data is 
submitted to the server. The public key data is submitted as 
a name/value pair, where the name is name as specified by 
the NAME=attribute of the BCEYGEN tag, and the value is 
the base64 encoded pubHc key. 

The following is an example form submission as it would 
be delivered to a cgi program by the fattp server: 

30 

commomiame = John + Doe & eioatl iK>body@companyx:oiii 
& org = Free +Enteiprisc + Coiporation & state = CA & 
country = US & key = MEgCQQCM2RcyvGcZlD9&2BBcb(in 
BR2GAYyKkaLjj8ov6yikH4B17Pkr3Gy3A%2BXH%2FLPi%0 
Apa46qBD9hJyqiNMa3gxhPpl\iC3TdAgMBAAE%3D 

35 

Certificate Downloading 

Support for a new MIME Content-TVpe has been added to 
the Navigator to facilitate downloading of user certificates. 
The new content type is referred to as "application/x-x509- 

40 user-cert". The content of the document is preferably a 
binary DER encoded X509 certificate. The default 8-bit 
encoding is used. X.509 certificate formats is supported, 
with the attributes described in this document. 
Cryptography in Secure Courier 

45 Cryptographic techniques are used throughout the docu- 
ment to provide privacy, authentication, and integrity func- 
tions necessary to meet the business requirements for elec- 
tronic commerce. Details describing the card holder 
merdiant connections as well as the merchant — acquirer 

50 coimection are as follows: 

The Card Holda: — ^Merchant connection. 
The general communications channel between the card 
holder and the merchant can be protected under a general 
security mechanism. However, the financial information and 

55 the confidential information communicated need to be fur- 
ther protected. The PI message is encrypted as a digital 
envelope under the acquirer public key to protect account 
information firom the merchant 
The Merdiant — Acquirer Connection 

60 A secure authenticated chaimel is provided for all com- 
muiucations between the Merchant and the Acquirer Gate- 
way to secure all messages exchanged. This channel uses 
DBS for bulk data encryption with RSAkeys for public key 
and key exchange operations. Other algorithms can be used 

65 The Payment Instiuction (PI) Message 

The PI message is handled differentiy from all the other 
messages in tiie Secure Courier system herein described. 
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This message is con^sed of the hash of the account or Queiy/Response kind of relationship. Each message is 

infonnation«thehashof the offer information, and other date made up of basic data types. These types are commonly 

and miscellaneous data. The message is enveloped using a grouped items, such as amount and currency, or are items 

pubUc key envelope and a DES symmetric key. The Card that are related in some way, such as payment instruction 

holder then signs the entire message and sends it to the 5 infonnation. 

merdiant. This method satisfies the export niles fw crypto- xhe following subsections describe the individual mes- 

graphic software and is available for use world wide. ^f the Secure Courier protocol. Following the message 

O&er Buyer-Merchant Messages definitions, a section is included that defines the subtypes 

TTieothermessagescomimjnicatedbet^^^ S^^^ Courier protocol: 

the merchant are encrypted using the secure transport Format 

mechanism discussed above if required by the merdiant or ^h^ description of the messages in this document uses an 

the buy<^. The merchant and buyer can determine intcrac- ^^^^^^ ^ notation is not a complete ASN.l 

tively whether a specific teansaction needs Fjvacy for &e specification, but is intended to be complete enough that the 

ordermformation, m which case a mechanism is estabhshed /^^^ thercsulting encoding is 

dimngtheshoppmg/negotmuonpro^^^ 15 completely specified. Many ofthe types may have additional 

msm can then be usod for the ord^ messages exchanged restrictions, such as requiring an all-nmneric field, where 

be^een the buyer and the merchant ^^^^ ^^^^^ ^ or Printable string types. 

Digital Mgnatures To achieve interopcrabiUty, both the content and the 

Signatures ^ used m secure courier to provide e^Jdence ^^^^ ^ j^e messages is specified While 

of the authorship of a message and noI^.repudlatlon for use ^ ^ ^^^^^^ ^^^^^^^ messages, it does not 

at a later tmie by the appropriate party Hie card holder ^ ^^^^ transmitted. It is 

provides a si^ature in the PI message, the merchant pro- ^^^^ ^ transmireach of these messages using any 

vides a signature in the offer message and in the receipt ^^^^ ^^^^^ ^^^^^ 3^1^ ^1^^.^^ 

message to the card holder, Tht acquirer only signs the ^ ^ ^j^^ associated with 

A«thenticationResiK)nsemessagetoa^^ 25 ASN.l;afoimof BO 8583, where particular message data 

tiie acqmrer signamre is not sent bade to me card holto .3 ^^^^^ ^ ^^^^ ^ j^^j ^^^^ ^ 

because acqmnng banks generaUy want to hide their identity ^^j^ ^^^^^^ ^^^^^ ^^^^^^y ^^^^^^ 

from buyCTs. IT ^ • 1, P • I^ER for encoding these messages. By specifying and 

/Jgonthim and Key SizesUsed m the Secure Coun^ ^^^^ ^ ^^^^ ^^^^ 

The specification of the above p-otoco does not identify 3^ j^^^ ^^^^ ^^^^ 

the partioilar ^gonthms used, TTie foUowmg discussion specification serves both as content Ust and encoding speci- 

presents the preferred ^gotithms and key sizes to be used for ^^^^ ^ p^^S #7 sped- 

secure couner to satisfy finanaal and e^oit requirements ^^^^ representing the envdoped data in Secure Cou- 

msinformaUonis specific to the preferred (^bodmient^ ^er messages. TTie ASN.l syntax is also used in the PACS 

imiy change in the fiiture according to stan^ 35 ^ specification for enveloped and signed data. By using 

m oyptographK Jdgonthms and secure levels of keys sizes, ^^^ ^ ^ ^^^^ Secure Courier inSsages, it is possible 

^ ^li • . , .f^' to use one format to describe the entire contents of a Secure 

Public Key Algonthms ^^^^ message. 

The RSA pubUc key algorithm is used for all pubHc key mnsaction 

qjerations and certificates, witii the following key sizes: ^ me Secure Courier Electronic Payment Protocol operates 

2048 bits for the root keys for Certification authonties; between three parties to a purchase transaction. The Mer- 

1024 bits for all signature only certificates; chant is offering goods or services for sale on the Internet 

768 bits for acquirers* key exchange certificates; The Buyer receives the goods or services, paying the Mer- 

5 12 bits far merchants and buyers* key exchange certifi- chant by presenting information about a credit card or debit 

Gates. 45 card account. The Merdiant will use this information to 

Synunetric Key Algorithms collect funds for the transaction through the services of an 

DBS is used for all bulk data encryption in the secure Acquirer. 

courier, induding the PI message, as well as all messages Payment Instruction (FI) 

between the Merchant and the Acquirer. The chaimel The payment instmction is not a message in the true sense 

between the buyer and the merchant can use any available so because it is never sent by itself between parties of the 

algorithm to encrypt data other than the PL For domestic transaction. However, it is central to the operation of the 

installations, RC4 with 128 bits key is used normally for Secure Courier protocol, motivating the contents of many of 

effidency reasons. For export purposes, RC4 with 40 bits the other messages. For this reason it is described first 

key is used. Other algorithms may be available for export Purpose 

into specific countries under various export regulations. 55 The Secure Courier Payment Instruction represents autho- 

Message Digest (Hashing) Algorithms rization by the Buyer to charge the q)propriate account for 

The secure courier uses MD5 for all hash functions, the goods and services delivered. The payment instruction is 

induding hash computations for signature purposes. The also designed to provide the following security features: 

only exception is MD2 for certifications requests t>ecause Hide the account number from the Merchant 

the PEM format specific to Certificate Signing Requests 60 Because account numbers are useful for transactions 

(CSR) uses MD2. outside of this payment protocol, it is beneficial to reveal it 

Message Formats in Secure Courier only where required. This has a desirable effect of hiding the 

The following discussion describes the messages that are account numbers from any attacker that may obtain access 

used in the Secure Courier Electronic Payment Protocol in to the Merchant's system 

detail. The protocol defines a set of messages that may be 65 Tie the payment authorization to a particular transaction, 

sent between the parties of a transaction. Many of these The Payment Instruction contains data that indicate the 

messages come in pairs, quite often in a Request/Response precise agreement between the Merchant and the Buyer. By 
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issuing the Slip, the Buyer indicates agreement to the 
transaction. By using it for payment, the Merchant also 
agrees to the contents of the transaction. 
Prevent overcharging for a particular transaction. 

The Payment Instruction contains a maximum monetary 
amount that is authorized for the transaction. 

The Merchant is allowed to request sums up to the 
indicated amount from the Acquirer. The Merchant may do 
this in one request, or in several requests made over time as 
goods are delivered. The Acquirer may deny requests for 
funds beyond the limit specified. In any case, amounts 
beyond the limit are subject to dispute by the Buyer. 
Provide a time-limit for diarging. 

The Payment Instruction contains an expiration time, after 
which the Acquirer may no longer allow the Merchant to 
charge the account. In any case, amounts charged to the 
account after the expiration date are subject to dispute by the 
Buyer. 

Provide Purchase Instruction tracking information for use by 
the Acquirer. 

The Acquirer may require that the Merchant provided a 
unique identifier for each Payment Instruction that is pre- 
sented for deposit A field is provided to verify the Mer- 
chant's identification of the data. 
Provide an optional signature by the Buyer. 

The signature (if present) may be used by the Acquirer or 
the Merchant to prove the identity and participation of the 
Buyer in the transaction. 

Contents 



bankcard contains information about the Buyer's aedit or 
debit card. This includes the card number itself (PAN) and 
several required or optional fields for authenticating the 
cardholder. 
5 Notes 

The formatted value is used in totalAmount because the 
Buyers* software displays the value for approval before 
including it in the Payment Instruction. Displaying a raw 
numeric string is not considered user-Mendly, so the proto- 
10 col requires that the Buyer approve the value that is stored 
in the Payment Instruction. The formatted value is checked 
and converted by the Acquirer when the Payment Instruction 
is opened. 

The meracqHash field is inydemented as a digest, rather 
15 than the original data, for two reasons: 

A portion of the data exchanged between the Merdiant 
and the Acquirer may be sensitive. For example, the 
identifier assigned to the Merchant may be useful in 
other contexts, and so should be kept private to tiie 
20 parties involved. 

A future change in the protocol may require additional 
data. By using a digest value here, the fonnat of the 
Payment Instruction is isolated from changes of this 
sort, and the Buyer's software does not need to be 
25 changed. 

The Buyer cannot validate the data represented by these 
fields in any case, so there is no loss in the capability of the 
Buyer. 

Purdiase Request Message 
30 The Secure Courier payment protocol begins after the 
Buyer has found one or more goods or services that are 
purchased from the Merchant. The Buyer begins the pay- 
ment protocol by transmitting a Purchase Request message 
to the Merchant. This message continues the shopping or 
35 negotiation portion of die transaction, and also lays &e 
groundwork for payment when an agreement is made. 
Purpose 

The Purchase Request message indicates that the Buyer 
believes that the list of goods and services is complete, and 
cuirentDate is the time that the Payment Instruction was 40 that all information required to describe the transaction has 



Paymemlnsmiction ::= SEQUENCE { 
version INIEC^R, 
currmtDatfi XJTCTuiie, 
expheDate UTCTime, 
totalAmount FGniiatted\foDey, 
orderHash DigestedData, 
meracqHash DigestedData, 
bankcard Cazdinfo 

} 



version of the slip 
date of agreement 
expiration date 
aj^eed total amount 
hash of description 
Merchant/Acquirer 
ciedit^debit card 



created. This value is used for tracking purposes. It is not 
used as an active ii^ut to the protocol. 

expireDate is the time at which the Payment Instruction 
expires. This field may be checked by the Acquirer and the 
transaction rejected if the slip is submitted by the Mer- 45 
chant past this date. 

totalAmount is the maximum total charges that the Merchant 
may make against this Payment Instruction. This field 
contains both a currency (in ISO 4217 fonnat) and a units 
field. The units field is a fomatted monetary value, 50 
including a currency symbol and decimal sq)arator as 
appropriate. The choice of currency symbol and separator 
should match those in general use for the ISO 4217 
currency indicated. 

orderHash is the result of a message digest function applied 55 
to a description of the transaction. The field is a PACS #7 
DigestedData type, which includes an algorithm identi- 
fier. The description itself need not be stored in the 
contentinf 0 p<Htion of the PACS structure, although there 



been transmitted to the Merchant. Note that the Purchase 
Request message itself may include portions of the data 
necessary to describe the order or it may refer to data 
previously sent 

The information that may be required includes: 

Item List (Including Quantities) 

The Buyer may also include prices in this message. Prices 
indicated by the Buyer are those that were in effect when the 
item was placed in the shopping basket If prices have 
changed a new price may be displayed for the Buyer, and the 
Purchase Request should be resubmitted with the new price. 

Shipping Destination 

This data is used to compute the required local taxes and 
the charges for shq)ping and handling. 

Transmitting the Purchase Request indicates that the 
Merchant should send any data that are required f<x the 
Buyer to generate an appropriate Payment Instruction for 
this transaction. The Buyer nuist also have transmitted any 
data that the Merchant requires to begin the payment pro- 



is no harm including it but is assumed to be a description 60 tocoL This data may be present in the Purchase Request 



of the order that was agreed upon by the Buyer and the 
Merchant. 

meracqHash is a hash of the data that is exchanged between 
the Merchant and the Acquirer with this I*urchase Instmc- 
tion. The nature of this data is unknown to the Buyer* but 65 
may include a unique identifier for the Slip that is used by 
the Acquirer to prevent multiple use by the Merdiant. 



message itself, or may have been transmitted previously. 
This data required by the Merchant may include: 
Payment Method 

For example, American Express, MasterCard, Visa, and 
debit card. These data are used to choose a credit card 
processing method, and may influence the choice of an 
Acquirer and die financial certificate associated with it. The 



09/16/2004, EAST version: 1.4.1 



5,671,279 



25 



10 



15 



merchant may also choose to adjust pricing based on the 
payment method. Note that this is not die credit card 
number, but only an indication of the payment method diat 
is used. 
Contents 

The contents of this message are not defined by the 
payment protocol. The fomiat may be any agreed upon by 
the Buyer and Merchant including, for exanq}le HTML and 
FEM. At a minimum, the message must include a session 
number that the merchant may use to retrieve data previ- 
ously transmitted. At most, it may include all the data 
necessary to describe the transaction. 

Generating Purdiase Request 

The Buyer follows the following steps when generating 
Purchase Request: 

Gather all appropriate data, including reference numbers 
for previously sent data. Format message as appropriate for 
the protocol in use. 

Processing Purchase Request 

The Merchant follows the following steps when receiving 20 
Purdiase Request: 

Determine whether all appropriate data have been 
received from the Buyer. Resume negotiations (shopping) if 
data is missing or outdated. Veriiy that data are correct, lliis 
includes checking Mds such as session numbers, item 25 
identifiers, and prices for correct format and values. Resume 
negotiations if data is incorrect Generate Qfi'er Message. 

Errors 

Jf the Merchant fails to receive the Purchase Request 
message, no Offer Message or other response is generated. 30 
The protocol may be terminated at this point The merchant 
may remove any state infonnation associated with this 
activity after an appropriate period of tune. 

If the Purchase Request message is received from the 
Buyer after the Merchant has removed or invalidated the 35 
associated state information, the Merchant may generate a 
message indicating the failure, and the protocol is termi- 
nated. 

If the Merchant receives the Purchase Request a second 
time, it should generate a new Offer message, assuming 40 
other checks on the data succeed. The merchant may cation- 
ally generate exactly the same Offer message, or a com- 
pletely new message. 

Offer Message 
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-continued 



[3] totalAmouot 


FannattedMoney, 




[4] expircDate 






[5] meiaoqHash 


DigestData, 


- PACS#7typc 


[6] acquirer 


Acquirerlnfo, 




p] merState 


OideiStatc, 




[8] signature 

} 


DatedSig 


- signature w/ date 



One implementation of this message is as an HTML 
document Each component of the message is sent as a 
tagged portion of the document, or as a tag optioa 

The Offer message includes: 
orderDesc is the description of the transaction. Hiis is the 
contract that is agreed to between the Buyer and the 
Merchant As such, it should include a list of items, 
quantities, and prices. It should also include the shipping 
method and address, along with any shipping charges and 
applicable taxes. For subscription services, the 
description, includes the type Of service and the time 
period covered. This data is in a Buyer-readable format 
orderDesc is included in the Payment Instruction as a digest 

to tie the payment with the description. 
ordezRef is a unique number assigned by the Merchant It is 
required to generate the Purchase Order message and is 
used to inquire about the state of the order if an error 
occurs during the transaction. 
meracqHash is a digest of several fields that are sent by the 
Merchant to the Acquirer. This field is used to construct 
the Payment Instruction. 
totalAmount is the maximum amount of money that the 
Merchant is allowed to collect for goods and services in 
this transaction. The client software uses this value to 
construct a Payment Instruction that is included in the 
Purchase Order message. This field includes both the 
currency and the units. The currency portion uses flie ISO 
4217 definitions for the currency. The units field is a 
character string contain the amount formatted for the 
currency used in the purchase. Ihe string is formatted this 
way so that it may be easily displayed to the Buyer. 
expireDate is the last time that charges should be made 
against the Buyer's account for this transaction. This 
value is included in the Payment Instruction so that it may 



be checked t>y the Acquirer. 

The Secure "Courier Offer message is sent from the 45 acquirer is information about the Acquirer selected by the 
Merchant to the Buyer in response to the Purchase Request Merchant This information is required by the Buyer to 
Puipose enveloped the Purchase Instruction data. This field con- 

The Offer message has three purposes: a certificate, identifying the Acquirer and its asso- 

Present the final description of the transaction to the public key. ^ , , 

Buyer for approval and for inclusion in the Payment 50 mcrState data is pnvate to the shopping protocol tts con- 



Instruction. 

Provide a reference number for this transaction in case an 
error occurs during the remainder of the protocol. 

Transmit additional data necessary for the Buyer to gen- 
erate a Payment Instruction for the transaction. 

The Merchant has the option to sign this message. 

Contents 

The Secure Courier payment protocol does not specify the 
entire content of the Offer message. The following ASN.l 
definition gives a general outline of the contents that may be 
present in this message. 



Offer ::= SET { 
[1] orderDesc 
[2] orderRcf 



Order, 

OrderReference, 



tents are not defined by the payment protocol, but are 
returned to the Merchant in the following Purchase Order 
message. This data may include such things as Order 
Number. The content of this data may depend on \^eth^ 
55 state information is maintained by tiie Merchant system 
during the shopping protocol. For example, it may be 
necessary to include the Shipping Address information 
here, so that the Buyer can send it again with the Purchase 
Order message. These data are generally in a Merchant- 
^ readable format, and is probably opaque to the Buyer. 
Order type 

Older: :=0C1ET STRING 

Order is what the Buyer's software should display as the 
65 ORDER. This is also the data that are used as input to the 
for future inquiry hash function to coni^ute H(ORDER). It is possible to save 

this information in the navigator. This allows the Buy^ to 
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show what data were displayed at the tunc the purchase was Record orderRcf, TxID, 

made. This is possible by saving the HTML source page in Optionally, generate a signature on the entire contents of 

a file, although a method that used mailboxes or folders is the message 

more user-friendly. Note that this value is different than Processing the Offer 

OrdcrState and OrderNum. Tlus is because fee Order type is 5 The Buyer performs the foUowing steps when receiving 

intended to be readable by humans. the Offer message; 

If theOrderNum and C^derState fields do not correspond Review the Order infoonation. Compute the message 

to the Orto, there may be a dispute when fee product h digest of fee Order giving orderHash. Check fee Acquirors 

delivered. In feis case fee Buyer should be able to show^^^ certificate. The certificate should belong to a trusted banking 

field is not returned to fee merchant. 1 L'k^^^^.k^. • 

OrderState lype special attnbutes that mdicate feat it belongs to an Acquirer, 

The OrderState component allows fee merchant to recal- example fee signer of an acquirer's certificate should be 

cuiate the exact contents and pricing of an order. * recognized card brand name, e.g. Master Card or VISA- 

15 Review fee totalAmount and expireDate fields. The Buyer 
should agree feat they are reasonable. In fee case of hard- 

OrderState SEQUENCE { goods, feey should correspond wife fee total purchase price. 

If all terms are acceptable, generate a Payment Slip using 

sin^u^o ofSSn^' totalAmount, expireDate. meracqHash, orderHash, fee cur- 

} 20 rent time, and envelope it using fee Acquirer's certificate. 

— — — — — — — — — Generate and send a Purchase Order Message to fee Mer- 

OrderNum represents a key for a record feat is kept by fee ^^^^ n,,,,^ „„vi, ^u- r 

merchant. This record contains fee actual purdhase , J^eBuyermay wish to save fee entire Offer message for 

information, and is used to check fee status of an order, 'f""^^"^ ^u^^'u ''"^^^^^ 

e.g. through anofeer HTML access. If fee merchant is ^ dcs^Pt^O" ^^^""^ purchase does 

keeping its own state, feen this record may contain fee Hst complete as expected. The Buyer should save at least to 

of items and fee shipping infonnation required for gen- o^^derRef field for use m eiror recovery, 

crating fee wder. In this case, fee following fields need not En-ors 

be provided. fee Buyer does not receive fee Offer message, fee 

ItemList contains fee items purchased. This is currently 30 Purchase Request message may be resubmitted, or fee 

transmitted to fee Merchant in a token generated by fee protocol may be terminated. The Buyer may always choose 

merchant and sent encrypted (may be also signed) to fee to terminate fee protocol wifeout responding to fee Offer 

client for fiirfeer references to fee transaction. message. 

Shippinglnfo is fee delivery address, and is used for Purchase Order Message 

delivery, shipping cost calculations, and tax calculations. 35 The Secure Courier Purchase Order message is sent by fee 

This field was sent in a previous form, prior to fee Buyer to fee Merchant in response to fee Offer message. 

OFFER, and is here only as a pass-through to ksep fee Purpose 

merchant from having to save state. It is preferably stored The PurchaseOrder message indicates that fee Buyer has 

in a special, undisplayed forms field. accepted fee offer given by fee Merchant The message 

Generating Offer 40 contains Secure Courier electronic payment information 

The Merchant performs fee following steps when gener- along wife order information required by fee shopping 

ating fee Offer message: software. 

Create fee Order information for fee Buyer and Order- Contents 

State to be returned wife fee Purchase Order. Generate an 

Order Reference number for fee purchase. This identifier is 45 —————— — 

vaUd for a certain period of time and must be distinct from =^ ^LL^. . ^ 

aUofeerOrderReferences.Selectanacquirertouseforfeis ofhonal. I^^cS^^"- 

transaction. The selection may depend on fee proposed [2jcSlip EnveiopcdData -PACS#7type 

payment mefeod indicated by fee Buyer. Once this selection PI sigoatme Datedsig optional - signature w/ date 



is made it cannot be changed because fee buyer uses fee so 

acquirer's public key to envelope private bankcard informa- — — 

merState includes all fee infonnation necessary for fee 

Con^te an appropriate total amount for this transaction. Merchant to reconstruct fee order. For protocols feat do 

For hard-goods purchases this should be fee total amount of not maintain any state in fee merchant at this stage, 

fee order, including exact amounts or allowances for taxes 55 mcrState must include all of fee previously provided Hat?' 

and shipping charges. For subscriptions or ofeer similar If fee merchant has maintained some state, feen merState 

purchases, this should be pre-aufeorized amount agreed may simply be an order number (OrderRef). This field is 

upon by fee Buyer and fee Merchant. completely uninterpreted by fee Buyer's software. 

Generate an expiration date for fee transaction. For hard- Ofeer information needed here may include: 

goods, this should allow for a reasonable delivery time. For 60 Item list. A list of all items and quantities included in fee 

subscriptions, fee expiration time might correspond roughly order. 

wife fee subscription period. Generate fee OrderState and Shipping Address (or ofeer delivery indicator)— to recom- 

Qrder information for fee Buyer. Generate a unique identi- pute fee taxes 

fier TxID which is used to identify fee Purchase Instruction Shipping Mefeod— to recompute fee shipping charges 

feat is received from fee Buyer. Compute fee digest function 65 addedData is additional data computed by fee Buyer feat 

of fee merchant's ID and TxID. This result is called mer- may be need by fee Merchant to con^lete fee transaction. 

acqHash. It is useful to include fee OrderHash value here. This 
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AudiRequest 


SEQUENCE { 




authAmouDt 


Money, 


0 to validate only 


meichaiit 


MerehantLifo, - 




trBDsactioQ 


TdD, 




totalAmount 


FomiattedManey, 




ccpiieDate 


UTCTimc, 




oidcrHash 


Ordeiflash, 




pnaliDcthod 


PaynisiitMethod, 




payment 


Eslip, 




batchscq 


BatcfaSeqnencG 


OPTIONAL. 


invoice 

} 


STRING 


OPTIONAL, 
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allows the merchant to check that its reconstructioD of the digest is used to provide message integrity. The hash is 

Offer matches what was sent to the Buyer. Another use of computed on the entire contents of the version, route, 

this field is to include salt data that the Buyer used for msgID and message fields, 

computing the OiderHash field. The Merchant must also AuthRequest Message 

use this data so that the result matches what the Buyer put 5 The AuthRequest message is sent from the Merchant to 

in the Payment Instruction. the Acquirer. 

Eslip is a Payment Instruction that has been enveloped with Purpose 

the public key of tiie Acquirer. In this way the payment Allows the Merchant to request authorization to collect all 

information, specifically the credit card nimiber and PIN, or a portion of the transaction amount from the Buyer. As a 

cannot be seen by the Merchant In addition, there is no spedal case, a request for no money requests the Acquirer to 

way for the Merchant to modify the meracqHash and validate the Payment Instruction and the Buyer's account 

orderHash fields that are stored there. data, 

signature is a public key signature in PACS #7 signData Contents 

format. The signature is conq>uted on the enveloped 

Payment Instruction (Eslip). 

Generating the Purchase O^der 

The Buyer pedbrms the following steps to generate a 
Purchase Order: 

Create a Payment Instruction firom data provided in the 
Offer message. Copy the orderState field firom the Offer 

message into the Purchase Order. Optionally aeate a sig- 20 
nature on the Payment Instruction field. 

Processing tiie Purchase Order 

The Merchant performs the following steps when receiv- 
ing a Purchase Order: 

Errors 25 

if the Merchant fails to receive the Purchase Order no authAmount is the amount of money that the Merchant is 

further processing occurs. The merchant may delete any requesting. This may be only a portion of the total amount 

state information that it maintains about the transaction after authorized by the Buyer fc3r this transaction, 

a reasonable time. Howeva, the orderRef value should merchant includes any data necessary to identify the Mer- 

never be given to any other transaction. 30 chant to the Acquirer. 

If die Merchant receives the Purchase Order after it has transaction is the TxID value that was generated to identify 

deleted any state information for it, it should indicate an the Payment Instruction. 

error. This error should be signed by the Merchant if possible totalAmount is the value that the Merchant believes is 

to indicate that it did ncrt accept the Purchase Order, and does included in the Payment Instruction. 

not use the Payment Instruction that was included in it 35 expireDate is the value that the Merchant believes is 

If die Merdiant receives the Purchase Order a second included in die Payment Instruction. 

time, it should regenerate the original response to the Buyer orderHash is the digest if the Order descrq)tion and should 

(Purchase Receim message). match what is in the Payment Instruction. 

Secure Courier Message Wrapper P^f^^^^ ]f ^"^^f ^''^^y '^""^^ ^^3^°^ 

M messages in the Secure Courier pr^^^^ 40 baShtq^Sce^^e^^^^^ 

Merchant and the Acquires: are contamed m a message ^^^l ^^y^ purposes. 

wrapper.. This allows the program reading the message from Generating the Aut&equest 

the communications channel to determine the type of the Machant performs the following steps to genraate an 

message, and take the appropriate response. This also serves AuthRequest message: 

as a second layer of an ^pUcation layer firewall for pro- 45 Qather together the TxID, totalAmount, expireDate, and 

tecting the Merchant-Acquirer channel. OrderHash corresponding to the transaction. Determine the 

Contents desired amount to be authorized. Determine tracking infor- 
mation (batchseq and invoice). Generate request including 

------------ the Payment Instruction firom the Buyer. 

=^^UENCE { 50 Processing the AuthRequest 

RoS^, AuthRequest is received by the Acquirer. Check the 

ins^ MessageType, merchant for validity and access. Verify that the transaction 

message ANY DEFINED BY msgid, has not been used and that the expireDate has not passed 

(figest DigestedData - PACS #7 type Compute the digest of the Merchant ID and TxID for 

' 55 comparing with meracqHash. 

Decrypt the Payment Instruction. Verify that the merac- 

version indicates the Secure Courier protocol version num- qHash and OrderHash in the PaymentSlip match the values 

ber that is being used. This field is set to 0 in this version supplied by the Merchant Verify that totalAmount and 

of the protocol expireDate in the Payment Slip match the values supplied by 

route is provided for use by the Merchant's software. It 60 the Merchant Verify that the amount requested by the 

identifies the originator of the message. Response mes- Merchant does not exceed the remaining value of die 

sages copy the routing information from the request so Payment Instruction. Authorize the transaction through the 

that it can be correctly returned to the original location. financial network. Generate the AutfaResponse Message and 

msgID indicates which of the messages in the following send to Merchant 

sections is present 65 Errors 

message contains one of the messages in the following If the AuthRequest Message fails to reach the Acquirer, no 

sections. response is generated or an error may be generated by the 
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network or application. The Merchant should resend the Contents 
request. If the Acquirer receives a duplicate AuthRequest 

message, it should resend the original response. — — - 

AuthResponse Message ^'C^f 

Purpose The AuthResponse message is the message 5 MeicSntinfo, 

returned from the bank network to the merchant in response batscq BatcbScqucnce, 

to an AuthRequest message. authanwuat Money, 

Contents «^ ESUp, 

autbData AuthBata, 
authdate XTTCnme 

10 } 

AuthResponse :^= SEQUENCE { Generating the Capture 

response StatusCodc, Processing tiie Capture 

data AuthData Capture Response Message 

} CaptureResponse SEQUENCE { 

AuthData type refuse StatusCodc 

AuthData ::= SEQUENCE { ^5 j 

code AuthCodc, Open Batch Message 

psd PaymentScrviceData, BatchOpcn :.•= SEQUENCE { 

avs AddressVcrificationCode OPTIONAL merchant Mcichantlnfo 

> } 

AuthCode type Open Batch Response Message 

AuthCodc ::= STRING size(6) OpcnBatchResponsc SEQUENCE { 



response StatusCodc, 



Payments erverData type _ 

PaymcntServiceData ;;= STRING 5izc(23) batch BatchID 

AddressVerificatioaCode type y 

AddressVerificationCode ::= STRING size(l ..5) close Batch Message 

Generating the AuthResponse Message BatchCIose ::= SEQUENCE { 

Processing the AuthResponse Message merchant Merchantlhfo, 

— — — — — — — — 25 batchID BalchID, 

invcrice STRING OPTIONAL, 



Notes 

It may be difficult to perform a combined form of Auth/ salcscount INTEGER, 

Capture. While this would be efiSdent from a message point credittotal Money, 

of view» it may be difficult to recover if the AuthResponse is 30 y integer 

lost before it is completely processed by the Merchant close Batch Response Message 

software. If the payment is already captured, the Merchant cioseBatchRcsponse :.•= sequence { 

software needs some way of querying the Acquirer to see if response stamsCode 

the capture had occurred. ^ 

Purchase Confirmation Message 35 

The Purchase Confirmation message is sent from the Query Batch Message 

Merchant to the Buyer. NOTHB: This is an optional message. Acquirers are not 

Purpose required to support this message. The Query Batch Message 

Content is sent from the Merchant to the Acquirer. It allows the 

The content of this message is not specified by the Secure 40 Merchant system to access the current balance for the open 

Courier protocol. However it should give some indication as batch. 

to whether the transaction completed successfully. If die 

Buyer fails to receive this message, the status of the trans- QueryBatch -= sequence { 

action is in doubt from his point of view. There should be nwrchant " Metchantinfo 

some method of determining the correct outcome. 45 batchiD BatchID OPTIONAL 

PiirchaseCoiif::=OCIFr STRING 'Bzich Status Message 

The Batch Message is sent in le^xmse to the Qijety Batch message. 

GeneratiBg Purchase Confinnation =^ - ^'^'Sdc. 

The Merchant must should save the results of the order batchiD BatchID. 

until the time ???? ^ balance Money 



Secure Courier Types 
ESlip type 



Processing Purchase Confinnation \ 
EiTQrs 

If the Buyer fails to receive the Purchase Confirmation, it ESlip ::= Contcnthifo ' " - fiom pacs #7 

cannot make any assimq)tions about the outcome of tiie — 

transaction. TVo options are avaflable: The ESlip is expected to contain PACS #7 envdopedData. 

The Buyer can resubmit the Purchase Order. This option The content of the packet is a Payment Slip. 



is valid for as long as the Merchant is willing to accept 
the order. The Merchant eithei' resends the Purchase — — — — 

Confirmation if the order was already processed, or go ^ 
redoes the entire order process if the original Purchase "~ size(i2) 

Order had not been received, cumncy string size(3) ' - iso 4217 vahies 



The Buyer can query the Merchant for the results of the ^ 

transaction. To do this the Buyer must have saved the -— — — ^— ^— ^— 

OrderRef field that was sent in the Offer message. 65 The amount field is expressed in the currency specified in 
Capture Message the following currency field. If a minor unit of currency 

Purpose applies, then amounts are expressed in the minor unit. (See 
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ISO 8583, Sea 4.3.11). The size (12 characters) comes from 
the current defimtion of this field in the ISO 8583 spec. 

The currency field is defined by ISO 4217. The message 
handling code may dieck this field for valid contents. The 
ISO 8583 document indicates that this is a three character 
alpha or a three character numeric field. 

Note that this type allows monetary values up to 12 digits 
in length. This a maximum value specified by the payment 
protocol Individual acquirers may put lower limits on the 
values that may be provided in the authorization and capture 
calls, and may support lower limits on balances as well. 

Merchantlnfo T^e 



Merchantliifo ::= SEQUENCE { 
MerehanLjd STRING size(l.,20) 

tcnninaUd STRING si2e(1..20) 

} 



TitlD ::= INTBGER 

Cardlnfo type 

CaidInfo::= SEQUENCE! 

PAN String sizc<9..19), 

expDate Striog size(4X 

IMPUCrr [0] AVSInfo 

iMPucrr [1] PIN 
} 



- MMYY format 
OPTIONAL, 
OmONAL 



AYS Jnfb ::= SEQUENCE { 




street String size(D..40), 




zipcods String size(0..9) 




} 




PINTVpe 


PIN ::= OCIET STRING size(8) 


64 bits. 


or 




PIN Cotttentlnfo - 


PACS encrypted 



10 



Txldiype 

The Txld type includes data that identifies a particular 
transaction for a particular merchant A transaction ED may 
be used only once. 



20 



25 



This type contains the information about the bankcard that 
is used for the purchase. All of this information is provided 
by the Buyer in preparation for sending the PurchaseQrder 
message. 

Notes 

The PAN field as defined is large enough only for a 
noimal credit card number. DEBIT card numbers are typi- 
cally longer. ISO 8583 provides for another field to hold the 
rest of the DEBIT card account number. 

AVSInfo Type 

The AVSInfo type provides the necessary data for per- 
forming address verification of a credit card. This is one of 
the possible forms of authentication. 



35 



40 



45 



50 



55 



The FIN is the pasonal identification number as entered 
by the buyer. ISO 8583 defines it as a 64-bit field. This data 
may be either the PIN itself or some derivative, presumably 
an encoded version. 

Issues 

If the PIN is encrypted the key used is preferably provided 
in the Acquirerlnfo type. For the presently preferred embodi- 
ment of the invention, the PIN (if present) is in the clear, 
with the entire Slip enveloped with the Acquirer's public 
key. 



60 
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AcquirerMo Type 



Acquirerlnfo SEQUENCE { 
Certificate 

} 



X509 Certificate 



Notes 

Jf desired, the invention may be adapted for use with 
various enveloping and signature protocols. This allows the 
Buyer to choose the algorithms appropriate for the particular 
acquirer. 

BatchSequence 



15 



BatchSequence ::= SEQUENCE { 
batch BatchXD, 
sequeoce NumericStimg size(0..10) 

} 

BatchID type 

BatchID ::= NumericString 8ize(0..10) 

StatusCode type 

StatusCode INTEGER 

Routclnfo type 

Routelnfo OCTET STRING size(8) 

DatedSi£ type 

DatedSig :?= SEQUENCE { 
^gnedDate UFCTIme, 
nonce OCTET STRING size(8), 

signatuie SigoedData - 



PACS #7 type 



30 Notes 

The signature field does not contain the data being signed. 
The signature represented by a DatedSig is on data found 
elsewhere. The signature field is con^tuted on that data, 
along with signedDate and nonce. 
The Acquirer Gateway Design Gtndelines 
The following discussion outlines some guidelines for 
designing and operating Ihtemet Acquirer gateways. 
Signing Up Acquirers 

An Acquirer is signed up by the card associations, Mas- 
terCard and VISA for example. An acquirer should present 
all the necessary information to the Certification authority 
managed by the specific card association. This process is 
typically done in person, while other processes may be done 
in an on-line manner fen* efSciency reasons. 

Merchant Registration and Certification Functions of the 
Acquirer 

The acquirer is responsible for registering and issuing 
certificates for the merchants. In this role, the acquirer 
receives the business papers from a merchant and performs 
the necessary checks to ensure the validity of the merchant 
The following items are given to each merchant firom the 
acquirer 

An acquirer merchant ID (MID) number, this number is 
unique for each acquirer— Merchant pair. A merchant 
may sign-up with more than one acquirer, in which case 
an MID is issued to the merchant by each acquirer: 
A merchant certificate, including all the necessary items 
required for 

electronic commerce as discussed above. As part of this 
process, the. relationship between the merchant and each 
merchant dictates the capabilities of the merchant as embed- 
ded in the merchant*s certificate. 
Access to the acquirer financial certificate for the mer- 
chant to obtain regular updates of the financial certifi- 
cate. Recall that the acquirer financial certificate is 
short lived and requires constant updates. 
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Value 


Descriptioii 


Provided by 


CCNAME 


Cicdh card type 


Buyer 


CCNUMBER 


Ciedh card number 


Buyer 


EXPMONTH 


Month of expiration 


Buyer 


EXPVEAR 


Year of expiratioa 


Buyer 


HOLDER 


Name of cardholder 


Buyer 


BIIiADDR 


Billing address of cardholder 


Buyer 


AMOUNT 


Total amount 


Merchant 


MID 


Merchant id 


Merchant 


TjOD 


Transaction id 


Merchant 
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Functions of the Acquirer Gateway for the Payment erated at the Merchant server, the same content is used by 

Protocol the merchant to generate the order hash independently. 

The responsibilities of the Acquirer gateway are discussed TWo attributes are valid with the PAYORDER tag, and 

above. In short, the acquirer gateway provides an interface both must be given. The NAME attribute specifies the name 

between the Acquiring bank and the Internet It processes the 5 to be paired with the PI value in the form submission. The 

Secure Courier messages on the Internet and maps them into ACQ^CEKT attribute names a certificate previously speci- 

the appropriate message format used by the acquirer. It is fied with a CERTIFlCArE tag. This certificate contains the 

important to note that there exists today many different pubUc key that is used to encrypt the PI. 

message formats supported by different acquirers and pay- In addition to the new tags, two new attributes are 

ment processors. T^e gateway should provide a modular lo preferably provided for input fields: 

method of supporting these formats in order to avoid chang- D*vivmri_. i 

. . , J • L . PAilNrQ=svalue 
ing the backend software in use by the acquirers. 

The Web Client Interface and Detailed Design The new PAYINFO attribute marks input fields that are 

The following discussion describes the interaction members of the PL Most of these fields must be provided by 

between the payment protocol and a World Wide Web client 15 the buyer (card holder); a few are provided by the merchant 

that provides the customer with access to the payment andmustnotbemodifiedby the buyer. In fact, except for the 

services as well as shopping and negotiations services. It is AMOUNT field, which must be shown to the buyer, the rest 

also possible for the Secure Courier mechanism to work of the merchant-provided fields can be of the INPUT type 

using an small-type transport, for non-interactive users. HIDDEN, which prevents the Navigator fi-om displaying 

After the buyer has gone shopping and agrees to purchase 20 them 

some item(s). the merchant (via the server software with 

which the buyer is interacting), shall display a FORM which 

lists the item(s) being purchased and instructs the buyer to 

enter specific information about the method of payment Via 

new HTML tags within the FORM, the merchant software 25 

can instruct the Navigator to create the Payment Instruction 

(PI). This PI is automatically created, encrypted, and 

returned to tiie merchant with the rest of the FORM fidds 

when the buyer SUfiMTTs. The PFs encryption is performed 

at a higher level than that of the session Itself, providing 30 

greater security for this particularly sensitive information. In 

addition, it is encrypted using the public key of the acquirer. 

Thus, the merchant can pass the PI along but cannot view or This information, along with the order hash, comprises 

modify the content the PI, and is encrypted using the public bey of the acquirer, 

HTML Forms Additions 35 found in the certificate named in tiie PAYORDER attribute 

One embodiment ofthe invention adds two new html tags. ACQ_CERr. This encryption provides that the merchant 

They are: does not gain access to any of the buyer's credit card 

information. To inform the user that these fields are being 

<CEKnFicAiH> . . . <ycEiaiEiCArE> treated differently, something about their display is made 

„ . ^ ^ t . ^ I. J J /viTAAs 40 different, e.g. tiiey have a key icon adjacent or a special 

jnm newtag trackman entire base64-enc^ background or border. In addition, there stould be a w^for 

•^'^f^" the «^er, upon seeing this display, to ask formoredetdled 

CAre tag IS aic NAME attribute, which is required for later security associated with each fidd or 

reference. The Navigator parses the certificate and holds ^ fields 

onto it while processing the rest of the document Hie READONLY 

certificate is not displayed unless the user specificaUy asks, ^^^^^ ^ .^^^^^ 

via documentinformation or a display button, to see it; or a ^^^^ ^^at tiie value should be displayed to die user, but 

preference option is selected tiia^ mstructs tiie Navigator to ^^^^^ ^ modify the value. To avoid 

'X^^^'f'^f H VK- A confusion, the field has a different background than tiiat of 

T^iJ^n. l^An. t 1^ t . ^0 a normal input field, me READONLYbackground is pref- 

ment s <IffiAD>^^.<^HEAI)> tags. Most navigators accept ^^^^^ document's backgr«id. 

the tag oubide, but merchants should not depend on this ^ ^^^^^ ^ m^Ms marked with 

when creatmgtiieir documents. a PAYINFO attribute are gathered together. The value of tfie 

The second new HTML tag is: PAYINFO attribute determines where the field belongs in 

<PAYORDER NAM&=^cxrACQ_CERT=^ame'> . . . </?AY- *® payment protocol PI message. The ordo- hash created 

ORDER> when parsing the PAYORDER is included. If any necessary 

information is missing, the Navigator displays an error. The 

This is actually a special type of INPUT tag, and must form response is not sent, or a standard error response is 

occur within a FORM. All text bracketed by a PAYORDER sent. Otherwise, the PI is encrypted using the public key 

tag is considered the order. This is a list of items being 60 firom the acquirer's certificate, base64 encoded, and sent as 

purchased, interspersed with HTML formatting tags. The a single value, paired with the NAME value of the PAY- 

entire content, including any HTML, is scanned and used in ORDER tag, to the server witfi the farm response. All other 

the creation of the hash of the order, which is sent in the PL form inputs are submitted normally. The bulk cipher used to 

The first character included in the hash is the one immedi- encrypt the PI is DBS for export purposes. The DES key is 

ately following the *>* of the opening <PAYORDER> tag; 65 encrypted under the acquirer's public key to form a digital 

the final character is that immediately preceding the *<* of envelope, 

the closing ^AYORDER> tag. Because the form is gen- Receipts 
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Receipts should be to sent back with the reply firom the 2. The system of claim 1, wherein all channel communi- 

submission. The merchant application provides the user with cations between any two nodes in said system are encrypted, 

means for saving and reviewing purchase receipts through 3. The system of daim 1, wherein said customer is 

the forms supplied using an email channel if needed. authenticated 

Example 5 4. The system of claim 1, wherein each message is hashed 

Given a base64 encoded X.509 certiiicate.XXX to avoid early termination type attacks, and to assure that 

The order consists of: messages arrive at a recipient unaltered. 

5. The system of daim 1, wherein confidential customer 
information is kept encrypted with regard to aU parties, 

1 pair of Mozilla boxer shorts (size MX induding a merchant that is handling a transaction. 

1 Netscape coffee mug, and 10 6. The systOTi of daim 1, wh»ein specific order infor- 

50 copies of the Netscape server. mation is maintained in confidence with regard to all parties 

Tbtai amount of order: $400.00 Other than said merchant 

S^t nSjct system of daim 1, wherein digital signatures are 

Month of Expiration: * Year of Expiradon: communicated tetween aU parties to ensure authorship 

Card Holder's Name- ,5 between two parties that are not necessanly commumcatmg 

Billing Address: directly with eadi other. 

' 8. The system of claim 1, wherein said secondary encryp- 
tion term defines encryption of message data fidds for 

The use of standards in Electronic commerce. decryption by a third party that is not necessarily a redpient 

The herein described electronic payment system includes of an entire message, 

the use of standard formats and protocols, as well as 20 9. The system of claim 1, wherein each secure courier 

commonly used de facto standards whenever possible. The message has a message wrqiper and a message body, 

following standards are used in Secure Courier: 10. The system of claim 9, wherein the message wrappa 

X.509 version 3 certificate formats. These formats are consists of at least one or more of an order nmnber, and 

emerging industry standards that are being employed routing information. 

by various commercial and governmental entities to 11. The system of claim 9, wherein for each message an 

issue digital certificates to individuals and entities. The acknowledge is generated by a rec^)ient and sent to a senda 

version 3 of the X.509 certificate format allows for ensure receipt of the message, 

several cptional attributes that can be used to identify system of claim 11, wherein said acknowledge is 

the certificate capabiHties and properties. The use of a * message that proves receqit by an appropriate 

flexible general purpose format makes it possible for f^"^^ ^ guarantee an authenti- 

different subsystems to interoperate using the same ^ated ^ 1 ■ 1^ 1. • ^- * 

certificates. TWsalsoaUowsfoTuseofmanyavailable O.Tlie system of dami 12, wheremtmie of receipt is 

commerdal products that can issue X.509 certificates concatenated to said hash and said concatenated message is 

in the finandal market us^as an acknowledge^ 

Tn. n-ui- XT o* J J r^A^^o . 14. Thc systcm of daim 1, who-em a messagc IS cousid- 

The Public Key QrotograpWc Standards PACS cryptc^ „^ ^ J^^^ ^ ^^ ^'^^ ^ , 

!!^'°T*'•P'^'"')I•'"*°S'!?°'^''y 35 period is ov«; and wherein a denial is opdonaUy provided 

seveid industrial and acadenncentiUes and have been Instead of an acknowledge, 

u^inthemajonty of applicatoonsusuig cryptographic 15 The system of cMn 1, further comprising: 

DERcSg(ASN.l)forf<^gthebasicmessagesto ' S^oSrafwift^S^aS^KJ 

be hashed, encrypted, signed, or enveloped, 40 ^ xuuv^ivu^, a.o « g^ut*ia«iig j^uivu«>*s 

Tc^co^ • ^"Tl^^^^ cuvwvi«H^ 4u orders, payment information (PI), and signatures for 

IS08583 IS used for a vanety of finanaal data types. transacttons. 

IS04217 is used for formats of amount and currency 16. The system of claim 15, wherein said customer 

^pes. application receives price and product information from said 

Although the invention is described herein with reference merchant and encrypts a transaction ID supplied ftom said 

to the preferred embodiment, one skilled in the art will 45 merchant witii a credit card number, where such information 

readUy appredate that other applications may be substituted is made accessible to said acquirer only using an acquirer's 

for those set forth herein without departing from the spirit public-key, which is extracted from an acquirer digital 

and scope of the present invention. Accordingly, the inven- certificate. 

tion should only be limited by the daims included below. 17. The system of daim 15, wherein said customer 

I claim: application verifies signatures from said merdiant to ensure 

1. A system for implementing electronic commerce over origination of messages, such that an order as supplied in a 

a pubUc network, comprising: receipt matdies an original order generated by a customer 

a secure transport layer induding a channel security earlier, 

mechanism comprising a keyed message digest 18. The system of claim 15, wherein said customer 

computation, wherein said secure transport layer sup- application generates signatures on payment messages using 

ports data privacy and integrity for communications a public key certificate, 

between any two network nodes, sudi that two secure 19. The system of daim 1, furdier coirpising: 

channels are provided, where there is one channd a merchant application for providing server functions for 

between a customer and a merchant and another dian- said customers to obtain product information and pric- 

nel between said merchant and an acquirer gateway iug. 

such that said merchant and said acquirer are authen- ^ 20. The system of claim 19, wherein said merdiant 

ticated to each other and to said customer; and application generates a transaction ID for a customer order 

a secure courier message for implementing an electronic to track said order until it has been authorized by said 

payment protocol that provides at least any of acquirer, wherein said transaction IDs arc generated sequen- 

signature, non-repudiation, and secondary encryption tially and used only once. 

terms wherein node-to-node authentication, privacy, 65 21. The system of claim 19, wherein said merdiant 

and data integrity are automatically achieved by said application verifies an acquirer signature on capture 

secure transport layer. responses and a customer signature on receipts. 
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22. The system of claim 19, wherein said merchant 
application generates receipts for customer signature. 

23. The system of claim 19, wherein said merchant 
application generates digests of order information for said 
acquirer to verify authenticity of a purchase order. 5 

24. The system of claim 1, further comprising: 

an acquirer application for receiving order amounts and 
transaction ID with customer financial information and 
for performing credit card authorizations. 

25. The system of claim 24, wherein said acquirer appli- 
cation receives capture requests and performs capture con- 
firmation. 

26. The system of claim 24, wherein aid acquirer appli- 
cation translates a standard message format from said mer- 
chant into proper formats used by an existing authaization 
network- 

27. The system of claim 1. wherein messages used in said 
payment protocol may include any of the following: 

PAN: a personal account number for a customer card; 

Expiration Date: an expiration date of said card; 

Merchant ID: a unique number for each merchant 
assigned by said acquirer upon signing up said 
merchant, said merchant ID being unique for each 
acquirer, and including an acquirer ID as part of it to 
generate a globally unique number, 

Transaction ID: a unique number assigned by said mer- 
chant for each transaction, wherein said merchant and 
said customer can use this number in conjunction with 
said merchant ID to identify any particular transaction; 

Acquirer Certificate; 

Merchant Certificate; 

Total Amount; 

H(Order); 

PIN; 

Billing address; 35 
Shipping Address; 

Resp-Code: a response code from an authentication pro- 
cess; 

Auth-Code: a number returned by a banking network to 

use for clcaring/capture steps; 40 
CaptureRcsp: a response for a capture process; 
Validity Period: start and expiration dates for a message; 
Date: date and time stamp; and 

Digital Signature: a digital signature comprising the fol- 
lowing: 

SIGNx(data)=Sx(data, nonce, date), nonce, date, sign- 
er's certificate. 

28. The system of claim 1, wherein a transaction ID 
(TxID), in which said PI value is encrypted so that a 
merchant server does not have any dear credit card numbers ^ 
that can be accessed remotely, is used to prevent a merchant 
from replaying authorization requests. 

29. The system of claim 28, wherein said transaction ID 
(TxID) is combined with credit card information and 
encrypted in a PI message to ensure that each such message 55 
is different when the merchant uses a unique TxID for each 
transaction. 

30. In an authorization group consisting of a customer, a 
merchant, and an acquirer, a transaction method comprising 
the steps of: 60 

sending a purchase-order, payment Instruction (PI) mes- 
sage to a merchant; and 

said merchant to responding with: 

SA/H(Purchase-Qrder, PI). Date, Time); 
where: 65 

H(value>=a message digest of value using a negotiated 
message digest algorithm- 
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31. The transaction method of claim 30, further compris- 
ing the step of: 

assigning a transaction ID CTxID) used for book keeping 
purposes and optionally to prevent a merchant from 
replaying authorization requests. 

32. The transaction method of claim 31. wherein said 
transaction ID TxJD is combined with credit card informa- 
tion and encrypted in a FI message to ensure that each 
message is different if said Merchant uses a unique TxID for 
each transaction. 

33. The transaction method of claim 30, wherein an offer 
from a merchant to a customer comprises the form: 

SIGNM(Validity Period, Items, Payment Method, zip 
code or country (for shipping charges computation), 
Amount, Currency, Merchant ID (MID), Acquirer's 
certificate (CEKTA), and transaction ID (TxID)). 

34. The transaction method of daim 30, wherein a pur- 
chase order from a customer to a merchant conq>rises the 
form: 

Name, Validity Period, Items, Total Amount, Currency, 
Merchant ID (MID), transaction ID (TxID), and ship- 
ping address. 

35. The transaction method of claim 30, wherein a PI 
message is a signed message from said customer using a Slip 
having the form: 

Version, current date, expiration date (Validity Period), 
Total Amount, Cuirency, Qrderhash, MerAcqHash, 
Credit Card information (Cardlnfo); 
where: 

Ordo^Hash of an order description including any salt for 
minimizing attacks on said hash; 

MerAcqhash:=hash of a merchant ID, transaction ID, and 
other merchant or acquirer data specific to a merchant- 
acquirer pair and not needed by the customer other than 
for inclusion in a FI message; 

CardInfo=(Personal account number (PAN, eviration 
date, other optional infonnation that may be needed by 
a payment processor/acquirer. 

36. The transaction method of claim 30, further conq)ris- 
ing tiie steps of: 

sending said FI encrypted to said acquirer using an 

acquirer's public key; and 
encrypting said FI message using a following digital 

envelope constmction as follows: 

E(SUp)=d»A{DES key K}. K(Slip); 
such that a final message sent is formatted as follows: 

PI=SINCE(E(SUp)); 
where: 

K{value}^alue encrypted under K using a symmetric- 
key algorithm; 

Cx, CERrx=a certificate of entity x; 

PKx{key}=key encrypted under a public key (PK) for x 
using a public-key algorithm, where x can be C for 
customer, M for Merdiant or A for Acquirer; 

E{value}=encryption of value under a data encryption 
key that is encrypted under a public key of a recipient 
and referred to as a digital envelope; and 

Sx(Value)=a value combined with the digital signature of 
the entity x using its private key, such that if entity x 
does not have a public-private key-pair, then a low 
grade signature can be generated using a hash of a value 
with information from x. 
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